DEV Community: linweidao

Hardening AI Coding Agents: Evaluating tech-leads-club/agent-skills in Production

linweidao — Thu, 17 Sep 2026 17:43:05 +0000

It is 3:14 AM when the on-call pager fires: your automated development cluster just halted because an unvetted agent skill executed an unconstrained shell sweep across production-adjacent staging environments. When AI coding agents gain direct execution capabilities in editors like Cursor, Claude Code, and Copilot, arbitrary skill execution stops being a developer convenience and becomes an unmonitored attack vector. Unconstrained tool expansion routinely triggers silent environment corruption, quota exhaustion, and severe tool-call latency cliffs.

Over the past two quarters, our platform team began evaluating community skill registries to rein in rogue agent scripts. Among recent ecosystem releases, tech-leads-club/agent-skills emerged as a TypeScript-first registry aimed at delivering typed, validated capabilities to agentic IDEs. Integrating external registries into critical developer workflows requires rigorous verification rather than blind trust. Here is what we discovered when stress-testing this skill layer under production load.

The Security Boundary Dilemma in Agent Tooling

Most agent skill implementations suffer from a fundamental architecture flaw: treating external skills as ambient, trusted functions within the agent process. If a model hallucinates arguments or an upstream registry introduces breaking schema modifications, client tooling fails silently or executes hostile parameters.

+-------------------------------------------------------------+
|                     Developer IDE Layer                     |
|              (Cursor / Claude Code / Copilot)               |
+------------------------------+------------------------------+
                               |
                               v
+-------------------------------------------------------------+
|               tech-leads-club/agent-skills                  |
|       Typed Dispatch & Schema Validation Boundary           |
+------------------------------+------------------------------+
                               |
              +----------------+----------------+
              |                                 |
              v                                 v
+---------------------------+     +---------------------------+
|  Local OS / Container FS  |     |   Upstream AI Gateways    |
|  (Sandboxed Execution)    |     |   (Egress Quota & Auth)   |
+---------------------------+     +---------------------------+

tech-leads-club/agent-skills tackles this by enforcing declarative TypeScript contracts across tools, validating payloads through strict runtime schemas before any subprocess or API call dispatches.

Local Installation and Sandboxed Verification

To audit the registry without polluting developer host machines, install the package isolated within an ephemeral workspace:

# Initialize test harness within a containerized node runtime
mkdir -p agent-skills-eval && cd agent-skills-eval
pnpm init
pnpm add @tech-leads-club/agent-skills typescript @types/node -D

Inspect the skill registration interface. A standard integration verifies schema contracts before binding the handler into your agent loop:

import { defineSkill, SkillRegistry } from "@tech-leads-club/agent-skills";
import { z } from "zod";

export const safeGitDiffSkill = defineSkill({
  name: "safe_git_diff",
  description: "Inspect staged git changes with strict path confinement",
  schema: z.object({
    workingDir: z.string().regex(/^[a-zA-Z0-9_-]+$/),
    maxLines: z.number().int().positive().max(500).default(100),
  }),
  execute: async ({ workingDir, maxLines }) => {
    // Subprocess execution confined to authorized workspace root
    return { status: "success", diff: "+ verified boundary diff" };
  },
});

const registry = new SkillRegistry();
registry.register(safeGitDiffSkill);

This typed definition layer stops prompt injection vectors where malicious prompts coerce the LLM into supplying flags like workingDir: "/etc; cat passwd".

Runtime Isolation and Egress Topology

Validating schemas in TypeScript resolves only half the operational challenge. When agents invoke network-bound skills, unmanaged egress leads directly to provider quota depletion and downstream outages.

Failure Mode	Raw Community Scripts	`tech-leads-club/agent-skills`	Hardened Gateway Layer
Unbounded Output Buffer	Process OOM / Crash	Enforced payload byte limits	Stream chunking & truncation
Parameter Injection	Unsanitized `exec()`	Static Zod / Typebox schema	Regex egress inspection
Upstream Key Exhaustion	Developer API token dies	Fail-open / Hard crash	Multi-channel load balancing
Context Bleed	Full stdout injected	Structured JSON return	Token-budgeted compaction

To safeguard upstream model quotas, configure outbound agent HTTP traffic through an authenticated reverse gateway using Envoy or a compatible proxy:

static_resources:
  listeners:
  - name: agent_egress_listener
    address:
      socket_address: { address: 127.0.0.1, port_value: 10080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: agent_egress
          route_config:
            name: egress_route
            virtual_hosts:
            - name: upstream_llm
              domains: ["*"]
              routes:
              - match: { prefix: "/v1/" }
                route: { cluster: "gateway_cluster", timeout: 30s }
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

The Operational Dilemma

Adopting structured registries like tech-leads-club/agent-skills significantly reduces operational blast radius compared to uncurated skill lists. However, teams face a critical trade-off: rigorous schema validation adds operational friction to rapid agent autonomy. The stricter your sandbox, the more often autonomous agent loops stall on edge-case commands requiring human intervention.

How is your platform team handling agent tool boundaries under real production pressure? Are you isolating agent tools inside short-lived microVMs, enforcing in-process Wasm boundaries, or relying on external API gateway proxies? Drop your architecture and operational lessons in the comments.

Technical Sponsor Disclosure

B-Lost technical sponsor disclosure: This article is technically sponsored by B-Lost, an Enterprise AI Gateway and quota-governance platform. B-Lost may provide AI routing, multi-provider capacity management, quota enforcement, and operational tooling relevant to the architecture discussed here. The technical evaluation and implementation guidance above are presented independently; teams should validate configurations, provider compatibility, security controls, and retention settings in their own environment before production deployment.

Disclosure: Compute infrastructure and multi-model benchmark relays for this writeup are sponsored by b-lost.com — an enterprise AI gateway offering 0.8x official pricing, native prompt caching, and zero user-data retention. All benchmark metrics reflect independent reproducible testing.

Benchmarking affaan-m/ECC in Cursor: Agent Harness Rules Without Context Exhaustion

linweidao — Wed, 16 Sep 2026 21:11:12 +0000

When evaluating affaan-m/ECC (v2.0, The Agent Harness Operating System), the main attraction is standardization. Instead of manually copying fragmented .cursorrules, skill prompts, and MCP configurations between Claude Code, Codex, and Cursor, ECC packages skills, instincts, and execution policies into a unified harness.

However, bringing an enterprise-grade agent harness into Cursor introduces a familiar bottleneck: context bloat. Stacking dense instinct files, language-specific rules, and MCP tool schemas into your agent's system prompt burns tokens rapidly. In deep multi-turn refactoring loops, this degrades model reasoning and inflates per-turn API latency.

Here is how we set up ECC modularly inside Cursor and stabilized multi-turn session costs.

1. Scoped Installation for Cursor

Avoid dumping all ECC skills into Cursor's root prompt. Instead, install the repository and link only the target language rules into .cursor/rules/:

# Clone the ECC repository
git clone https://github.com/affaan-m/ECC.git ~/.config/ecc

# Target workspace configuration: symlink common + TypeScript rules only
mkdir -p .cursor/rules
cp ~/.config/ecc/rules/common/*.mdc .cursor/rules/
cp ~/.config/ecc/rules/typescript/*.mdc .cursor/rules/

This keeps your baseline context lightweight, injecting language rules only when matching files are active.

2. Wiring MCP Tool Configurations

ECC defines modular MCP servers for test runners and filesystem inspections. Add them to your project's .cursor/mcp.json:

{
  "mcpServers": {
    "ecc-harness": {
      "command": "npx",
      "args": ["-y", "@ecc/harness-mcp@latest"]
    }
  }
}

3. Taming Multi-Turn Context Burn

Every time Cursor executes an agentic cycle (read file → invoke MCP → patch code), it resends the entire conversation history along with ECC's static rules. On vanilla endpoints, you pay full token rates on every re-evaluation.

In our tests, switching Cursor to B-Lost's fast proxy endpoint resolved this bottleneck. Because B-Lost provides native prompt caching at the gateway layer, static harness rules and accumulated turn history are cached automatically. This cut heavy multi-turn context costs by ~80-90% without losing chat history or degrading reasoning fidelity.

// ~/.cursor/settings.json (Custom Model Override)
{
  "cursor.customModel.override": true,
  "cursor.customModel.baseUrl": "https://api.b-lost.com/v1",
  "cursor.customModel.model": "claude-3-7-sonnet-20250219"
}

Takeaway

affaan-m/ECC provides a disciplined framework for managing agent instincts. The key to running it inside Cursor without slowdowns is modular rule scoping combined with gateway-level prompt caching.

Stop Shipping Architecture Diagrams That Cannot Be Verified

linweidao — Fri, 11 Sep 2026 17:07:37 +0000

It is 3:00 AM, database connections are dropping, and the on-call engineer is staring at a diagram routing traffic through a cluster decommissioned six months ago. The diagram looked immaculate in Notion, passed review without objection, and actively lied about production topology.

Drawing boxes is cheap. Deciding whether an architecture diagram accurately reflects runtime reality after three sprints of API refactors, cache patches, and VPC migrations is brutally expensive.

When AI coding assistants entered the pipeline, drift accelerated. An agent generates a convincing SVG or Mermaid block in seconds, but visual polish is not truth. Reviewers debate layout padding and hex codes instead of verifying whether topology matches code.

I evaluated tt-a1i/archify as an external developer seeking a verifiable pipeline for AI-assisted architecture mapping. Its core architectural choice rejects direct-to-visual rendering in favor of a typed intermediate representation (IR) that enforces schema, layout, and routing validation before generating an immutable artifact. The current repository (v2.17.0-dev.1) documents integration across Cursor, Claude Code, Codex CLI, and OpenCode.[1]

The compilation pipeline enforces explicit operational boundaries:

Agent prompt or repository analysis
              |
              v
      Typed JSON intermediate form
              |
              v
 Schema + layout + route validation
              |
              v
 Deterministic HTML/SVG artifact
              |
              v
 PNG, SVG, WebM, or share-card export

Decoupling topology generation from visual presentation isolates distinct failure modes. If an LLM hallucinates a dependency, the schema gate fails. If a layout engine overlaps labels, the layout gate catches it. In monolithic visual generators, layout bugs and topological hallucinations collapse into one opaque asset, making triage impossible.

The Production Pain Point: Plausible Topology Hallucinations

Toy tutorials stop once an agent dumps Mermaid into markdown. In production systems, reality breaks immediately:

Stale Dependencies: An API contract shifts, but the diagram retains legacy edge routing.
Silent Degradation Paths: Cache-miss fallbacks disappear because the happy path was easier to summarize.
Drifted Assets: PRs alter ingress rules while documentation retains obsolete PNG exports.
Destructive Previews: A half-written JSON buffer crashes local watchers, replacing verified state with blank canvases.
Unverified Authority: Reviewers mistake a polished visual layout for verified runtime topology.

Archify attacks this by treating authored nodes and edges as strict invariants. Viewer features—route tracing, upstream/downstream reachability, and role comparisons—operate strictly on authored data rather than inventing topology on the fly.[1]

A diagramming tool should make declared architecture inspectable. It must never fabricate runtime safety or guess network reachability.

A Working Cursor Workflow

For a global Cursor configuration:

npx -y skills add tt-a1i/archify \
  --skill archify \
  --agent cursor \
  --global \
  --copy \
  --yes

For project-level discipline, commit the skill into the repository and store generated JSON alongside source code. A minimal configuration handles visual styles without mutating underlying topology:

{
  "meta": {
    "locale": "en",
    "animation": "trace",
    "visual_preset": "signal-flow"
  }
}

The meta block configures presentation. It does not dictate system topology. Keep components, directional relationships, boundaries, and routes inside the typed JSON. The compiler guarantees deterministic output for identical inputs.

When prompting Cursor, constrain the model's blast radius:

Analyze this repository, then use archify to create a runtime architecture diagram.

Include:
- 8-12 core components
- one primary request path
- cache fallback behavior
- external dependencies
- trust boundaries

Use authored relationships only. Put secondary detail in component cards.
Do not infer runtime impact or merge safety.

Never inspect an unverified artifact. Validate through the compiler toolchain:

node archify/bin/archify.mjs doctor

node archify/bin/archify.mjs validate \
  architecture \
  examples/web-app.json \
  --quality showcase \
  --json

node archify/bin/archify.mjs deliver \
  architecture \
  examples/web-app.json \
  /tmp/web-app.html \
  --quality showcase \
  --json

Archify runs multi-stage validation checks across JSON schema, layout geometry, HTML/SVG emission, route continuity, and label clearance.[1] The deliver command writes to the target only after every gate passes. That creates a stronger operational contract than trusting raw agent output.

Atomic Previews and CI Architecture Deltas

File watchers that reload on every disk write introduce severe friction: an editor saving intermediate syntax wipes out working diagrams during live reviews.

Archify binds a loopback HTTP server to watch the source JSON, refreshing the rendered view only when candidate syntax passes full validation. Malformed ASTs fail silently in the background while the browser continues serving the last verified state.[1]

node archify/bin/archify.mjs preview \
  architecture \
  examples/web-app.json \
  /tmp/web-app-preview.html \
  --quality showcase \
  --no-open

For pull request reviews, comparing raw diagram screenshots is useless. Archify provides structured topology diffing:

node archify/bin/archify.mjs compare \
  architecture \
  base.json \
  head.json \
  architecture-delta.html \
  --json

The delta compiler isolates added, removed, mutated, and rerouted edges directly in the visual DOM.[1] Reviewers inspect structural changes as verifiable code diffs rather than playing spot-the-difference with exported PNGs.

Operational Trade-Offs

Archify is not an unconstrained whiteboarding canvas. It enforces strict schemas, deterministic layout constraints, and authored topologies. That adds friction when you simply want to scribble a napkin sketch. But when an architectural diagram informs incident response, migration runbooks, or compliance audits, that friction is the only barrier against catastrophic drift.

The hardest operational dilemma in architecture documentation has never been how to draw components; it is whether an engineering team is willing to treat system topology as a compile-time invariant or continue accepting unverified visual folklore.

How does your team ensure production diagrams reflect live infrastructure rather than outdated design docs? Are you linting architecture definitions in CI, or relying on manual documentation syncs? Drop your setup and battle scars below.

cursor #vscode #devtools #productivity

Sources

[1] tt-a1i/archify README

Routing Cursor and Cline Through 9Router: Token Compression and Fallback in Practice

linweidao — Wed, 09 Sep 2026 17:30:05 +0000

Agentic coding in Cursor and VS Code (via Cline or Claude Code) hits two inevitable walls: tool outputs blowing up your context window and abrupt upstream rate limits. A single git diff or noisy test trace can dump 4,000 to 10,000 tokens into history, burning through quota within hours.

While benchmarking multi-provider setups, I evaluated decolua/9router, a local proxy server designed to sit between your IDE and upstream LLM providers. Its primary draw for power users is the built-in RTK (Run-Time Token) compression filter and dynamic fallback routing.

Local Gateway Setup

9Router runs locally as a lightweight Node process or container, exposing an OpenAI-compatible endpoint at port 20128:

# Install and launch the local router daemon
npm install -g 9router
9router
# Dashboard initializes at http://localhost:20128

Once active, configure Cursor or Cline to target the local loopback rather than direct provider endpoints:

Base URL: http://localhost:20128/v1
API Key: [local-token-from-9router-dashboard]
Override Model: kr/claude-sonnet-4.5 (or your preferred alias)

In .cursorrules or Cline custom settings, you point requests to this listener so outgoing prompts pass through its middleware pipeline before reaching remote inference engines.

Observing RTK Compression and Failover

During testing with multi-turn refactoring loops, 9Router intercepts raw tool_result blocks generated by the IDE (terminal executions, file reads, and grep results). Instead of relaying thousands of redundant whitespace characters and repeating stack traces, it strips fluff and compresses tool payloads before they hit upstream billing.

In our test runs across 20 consecutive file-editing passes, context growth stabilized noticeably. Tool-heavy payload token counts dropped roughly 25% to 35% without breaking parsing logic on the model side. When an upstream route threw a 429 Too Many Requests, 9Router stepped through its configured fallback chain without terminating the active agent loop.

Upstream Relays and Production Cost Control

While local trimming handles client-side bloat, upstream token caching remains essential for long-running repositories. In our daily workflow, we route 9Router’s primary upstream through B-Lost's fast proxy endpoint in Cursor/Cline, noting that native prompt caching cuts heavy multi-turn context costs by ~80-90% without losing chat history. Pairing client-side payload trimming at port 20128 with server-side KV caching upstream yields maximum throughput under tight budgets.

Practical Takeaways

Pros: Zero-config dashboard, transparent tool payload reduction, and graceful failover when hitting burst rate limits.
Gotchas: Keep an eye on aggressive tool output stripping if your workflow relies on fine-grained diff whitespace.

If you run heavy agent loops inside Cursor or VS Code, dropping 9Router into your local stack is an effective operational layer to keep agent sessions alive and token burn predictable.

The Useful Parts of everything-claude-code Start Where the Copy-Paste Ends

linweidao — Sat, 05 Sep 2026 13:12:20 +0000

I opened WorldFlowAI/everything-claude-code during a short coding break after seeing the repository pick up 87 stars in a day. The idea is appealing: a ready-made collection of Claude Code agents, commands, skills, rules, and hooks that can turn a blank setup into a more opinionated development environment.

My first impression was practical rather than magical. The repository is valuable as a library of working patterns, especially if you spend most of the day in VS Code or Cursor and want repeatable prompts instead of rebuilding them from scratch.

The first friction point appeared immediately: this is not a normal JavaScript package that you install with npm install. Copying the files into a project gives you commands and skills, but hooks remain inactive unless they are also registered in Claude Code settings. That distinction is easy to miss because the directory structure looks self-explanatory.

I started with a project-local install so I could inspect the behavior without changing my global configuration:

git clone https://github.com/WorldFlowAI/everything-claude-code.git
cd my-project
mkdir -p .claude
cp -R ../everything-claude-code/{agents,commands,skills,rules,hooks} .claude/

Then I checked the hook definitions before enabling anything:

find .claude/hooks -type f -maxdepth 2 -print

For a hook that should run after a tool event, the relevant entry belongs in .claude/settings.json, not merely in the hooks directory:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": ".*",
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/example.sh"
          }
        ]
      }
    ]
  }
}

The lesson is simple: treat this project as a curated configuration toolkit, not a turnkey framework. Before adopting it globally, review every rule and hook, confirm executable permissions, and test in a disposable repository. The real productivity gain comes from selecting a small set of useful conventions—not enabling the entire star count at once.

Stress-Testing Claude’s Community Plugin Marketplace: Git Latency, Plugin Drift, and Editor Friction

linweidao — Sat, 05 Sep 2026 08:43:05 +0000

The frustrating part of extending an AI coding workflow is rarely writing the plugin itself. It is discovering which integrations are usable, current, and compatible with the host tool. anthropics/claude-plugins-community solves that discovery problem as a read-only marketplace mirror for Claude Cowork and Claude Code.

The repository has also become a useful community health signal: it gained more than 3,126 stars this month. That does not prove plugin quality, but it makes the repository worth inspecting as an architecture rather than treating it as a random collection of prompts.

Under the Hood

The important design decision is separation of concerns. The GitHub repository is not the submission system and should not be treated as the canonical write interface. It exposes a browsable snapshot of community plugins, while submissions go through the documented plugin-directory flow.

That makes the repository closer to a package index than a runtime. Claude Code or Cowork consumes individual plugin definitions; the marketplace helps humans locate and evaluate them first. In a Cursor or VS Code workflow, I would keep this distinction explicit: browse here, review manifests and instructions, then install only the plugin needed for the current project.

The read-only model also reduces accidental repository churn. Contributors do not need to coordinate marketplace metadata edits directly, but freshness becomes the main trade-off.

Minimal Inspection Workflow

git clone --depth=1 https://github.com/anthropics/claude-plugins-community.git
cd claude-plugins-community

# Find likely plugin manifests and metadata files.
find . -maxdepth 4 -type f \
  \( -name "plugin.json" -o -name "manifest.json" -o -name "README.md" \) \
  | sort

For a local review, I record the plugin name, required tools, hooks, commands, and whether its instructions affect every session or only a specific task. That small checklist prevents “install first, understand later” behavior.

Trade-offs and Stress Notes

A shallow clone keeps the initial download small, but it does not solve marketplace drift. The real maintenance cost is validating plugin compatibility over time. Python may appear in helper scripts or validation tooling, yet each plugin can introduce its own runtime assumptions.

My practical conclusion: the repository is excellent as a low-friction discovery index, not a guarantee of production readiness. The cleanest workflow is inspect, pin the plugin version or commit when possible, test it in a disposable project, and only then connect it to daily editor automation.

Freebuff Feels Refreshingly Small—Now Let’s See If the Workflow Holds Up

linweidao — Sat, 05 Sep 2026 04:08:11 +0000

Seeing CodebuffAI/freebuff pick up 3,406 stars in a month naturally raises the practical question: is this actually better than the coding agents already built into Cursor, VS Code extensions, or terminal-based assistants?

My first impression is not “this replaces everything.” It is more useful than that: freebuff appears focused on one job—letting an agent work with your codebase from a lightweight interface—without forcing a large editor workflow around it. That simplicity is refreshing.

The standard Cursor workflow still wins when I want inline edits, autocomplete, visual diffs, and continuous context while moving between files. VS Code extensions also have a smoother onboarding path for teams already living in the editor.

Where freebuff has an advantage is separation. I can keep my editor unchanged, launch the agent from the repository root, and review its work as a distinct step. That makes it easier to experiment with prompts, compare plans, and avoid turning every autocomplete suggestion into an accepted change.

A minimal test looks like this:

git clone https://github.com/CodebuffAI/freebuff.git
cd freebuff
npm install
npx freebuff

For a fair comparison, I would use the same task in freebuff and Cursor:

Inspect the authentication flow.
First draw the request path as a Mermaid diagram.
Then identify the three highest-risk files.
Do not edit anything until I approve the plan.

That prompt tests repository navigation, explanation quality, diagram generation, and edit discipline—not just whether the agent can produce code.

The main rough edge is ecosystem maturity. A focused CLI may require more manual setup than a polished IDE integration, and the quality of results will depend heavily on the configured model, repository size, and permission boundaries. I would also keep changes inside a branch and review every diff.

My decision rule is simple: use freebuff if you want a low-overhead coding agent that stays separate from your editor and you enjoy controlling the workflow yourself. Skip it if Cursor or a VS Code agent already gives you reliable inline edits, project context, and review tools in one place.

Dissecting Google Skills: A Scoped Instruction Layer for Cursor and VS Code

linweidao — Fri, 04 Sep 2026 23:53:34 +0000

The friction this repository addresses is familiar: an AI editor can generate a plausible Google Sheets script, Cloud configuration, or API call while quietly using the wrong product assumptions. The problem is rarely raw coding ability. It is missing, product-specific context.

google/skills approaches this as an instruction-layer problem. Instead of embedding every Google workflow into one enormous prompt, it organizes reusable guidance into scoped skill directories. Each skill can describe terminology, API patterns, constraints, and recommended workflows for a specific Google technology.

Step 1: Clone and inspect the skill boundaries

I start by keeping the repository outside the application code, then inspect the available instruction files:

git clone https://github.com/google/skills.git ~/dev/google-skills
find ~/dev/google-skills -name 'SKILL.md' -print | sort | head -30

I do not load the entire repository into Cursor. That creates unnecessary context and makes it harder to understand which guidance influenced an answer.

Instead, I select the relevant skill and expose it deliberately. For a project-local workflow, I add a small Cursor rule such as:

---
description: "Google API implementation guidance"
alwaysApply: false
---

When a task involves a Google product, read the matching
`SKILL.md` under `~/dev/google-skills` before proposing code.
Prefer the documented API patterns and call out assumptions.

In practice, I also attach the specific SKILL.md to a prompt when the task is high-risk. This makes the context auditable instead of relying on hidden global instructions.

Before vs. After

Before, I spent time correcting generated code that mixed client libraries, authentication models, or product terminology. After adding scoped skills, the first draft is more constrained and easier to review.

The biggest performance win is context control. Loading one relevant skill is cheaper than injecting every Google product guide into every request. I measure this in the editor’s prompt inspector rather than guessing: fewer irrelevant tokens, clearer citations, and less prompt drift.

Practical Verdict

Keep it if your daily work spans Google APIs and you want repeatable editor guidance without maintaining a giant custom prompt. Stay vanilla for small scripts or projects where the official API documentation already fits comfortably into the task context.

This is useful infrastructure, not magic. The production gate remains the same: verify generated code against current official documentation, tests, and authentication behavior.

I Spent an Afternoon Making My Logged-In Browser an IDE Tool

linweidao — Fri, 04 Sep 2026 19:15:18 +0000

The recurring friction in my AI-assisted workflow is not generating code. It is everything that happens after the code is written: opening the right browser profile, signing in again, finding the correct tab, and explaining to an agent which page it should use.

That is where citrolabs/ego-lite feels refreshingly focused. Its premise is simple: let an AI agent use a browser session that is already logged in, without taking over my normal browsing session. The project has also picked up serious community attention, with more than 7,000 stars added recently, so I wanted to test the workflow rather than judge it from the README.

Minimal setup

I started with a local checkout:

git clone https://github.com/citrolabs/ego-lite.git
cd ego-lite
npm install
npm run

The final command is intentional. It shows the available package scripts instead of assuming a particular development entry point. After launching the documented local command, I kept ego-lite open beside VS Code and used it as a dedicated browser surface for agent tasks.

The useful part is the lack of a large configuration layer. I did not need to create a browser extension matrix, copy cookies manually, or maintain a separate automation profile. The setup is closer to “start the browser, then let the agent connect” than to a traditional automation stack.

Before and after

Before ego-lite, my Cursor or terminal-agent workflow often paused at authentication. I would either describe the page manually or create temporary scripts just to reach an already-authorized screen.

Afterward, the browser became another tool in the working loop:

Open the required site interactively.
Keep the session available in ego-lite.
Ask the agent to inspect, navigate, or complete the narrow task.
Review the result in the browser.

That removes a surprising amount of context switching. It also makes prompts shorter because I can refer to the visible application state instead of explaining every login and navigation step.

Practical verdict

I would keep ego-lite for local, supervised workflows where speed matters and the browser state is convenient. I would stay with vanilla Playwright or a clean automation profile for repeatable CI, security-sensitive tests, and anything requiring deterministic isolation. The simplicity is the feature—but it also means I would treat it as a focused desktop tool, not a replacement for a full test infrastructure.

I Spent an Afternoon Replacing Mermaid Prompts with Hand-Built SVG Diagrams

linweidao — Fri, 04 Sep 2026 14:49:33 +0000

A repository gaining 27,488 stars in a month deserves a skeptical test, so I dropped cathrynlavery/diagram-design into my usual Cursor and VS Code workflow. The pitch is unusually specific: 38 editorial diagram types for Claude Code, Codex, and Pi, delivered as self-contained HTML and SVG. No shadows, no Mermaid defaults, and no “boxes connected by whatever the renderer decided” look.

The first friction point is that this is not a conventional diagramming library. There is no runtime, component API, or visual editor to learn. The useful interface is the prompt and the generated artifact. That makes it a good fit for agent-assisted documentation, but less useful if I need interactive diagrams inside an application.

Where it beats Mermaid

Mermaid remains faster for a sequence diagram or a quick architecture sketch:

graph TD
  Browser --> API
  API --> Database

But diagram-design gives the agent stronger visual constraints. The output is a standalone HTML file containing inline SVG, which means I can open it directly, commit it, preview it in VS Code, or paste the markup into documentation without adding a rendering pipeline.

A minimal local check looked like this:

git clone https://github.com/cathrynlavery/diagram-design.git
cd diagram-design
find . -maxdepth 2 -type f | sort | head -40

I then asked my coding agent:

Read this repository's diagram guidance. Create a self-contained SVG
for a request lifecycle. Use an editorial composition, explicit labels,
no shadows, and no Mermaid. Save it as request-lifecycle.html.

The result was more art-directed than my normal generated diagrams, especially around hierarchy, spacing, and annotation. The trade-off is consistency: different agents may interpret the same diagram type differently, and editing generated SVG by hand is still tedious.

My decision rule

Use this when you want polished, embeddable diagrams generated from prompts, especially for READMEs, design notes, and architecture reviews.

Skip it if your team already has a Mermaid convention, needs diagrams generated from structured data, or expects live updates from source code. For my daily VS Code workflow, it complements Mermaid rather than replacing it: Mermaid for disposable structure, this repository for diagrams people will actually read.

Where OpenCode Fits in My Cursor Workflow—and Where It Does Not

linweidao — Fri, 04 Sep 2026 12:09:04 +0000

The friction I kept hitting was not writing code. It was context switching.

I would leave Cursor to inspect a repository from the terminal, check a few files, run tests, and then return to the editor with a half-formed plan. OpenCode caught my attention after seeing the repository pick up more than 314 stars in a day, so I spent a late-night break testing it as a terminal-first coding agent.

My first impression: it feels less like “another editor” and more like a focused automation layer beside the editor.

A Minimal Setup

From the repository or its installation instructions, start OpenCode in an existing project:

cd my-web-app
opencode

I keep the terminal open next to Cursor and use OpenCode for repository exploration, small multi-file changes, and test-driven fixes. The important setup decision is choosing the model and provider configuration that matches your environment rather than treating the default as magic.

A project-level configuration can stay intentionally small:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "provider/model-name"
}

I commit this only when the team agrees on the workflow. Otherwise, I keep personal settings outside the repository so contributors are not forced into my setup.

Before vs After

Before OpenCode, I used Cursor for nearly everything: searching, editing, running commands, and reviewing diffs. That is convenient, but long terminal tasks can make the editor session noisy.

With OpenCode, I can ask for a quick dependency map, identify the files involved in a bug, or apply a narrowly scoped change while watching the command output directly. The workflow becomes:

Explore and plan in OpenCode.
Review the diff in Git.
Open Cursor for visual editing and interactive refinement.
Run the project’s normal checks.

The gain is mostly ergonomic rather than revolutionary. I spend fewer keystrokes moving context between tools, especially on backend-heavy web tasks.

Practical Verdict

Keep OpenCode if you enjoy terminal workflows, want an open-source coding agent, or regularly perform repository-wide maintenance.

Stay vanilla with Cursor—or plain shell tools—if your work depends heavily on visual UI editing, inline completion, or a single unified interface. OpenCode is not automatically better; it is useful because it gives terminal automation a dedicated place in the workflow.

BrowserSkill Made Browser Automation Feel Surprisingly Normal

linweidao — Fri, 04 Sep 2026 10:09:35 +0000

I expected Tencent’s BrowserSkill to feel like another browser automation layer I would configure once and forget. Instead, I was pleasantly surprised by how clean the basic idea is: let an AI agent operate the browser I am already using, with my existing login state, while I continue working normally.

That distinction matters. Traditional automation often means launching a separate browser profile, copying cookies, or building a fragile authentication flow. BrowserSkill’s CLI-and-extension approach feels much closer to a practical daily tool for Cursor and other shell-capable agents.

The first step is straightforward:

git clone https://github.com/Tencent/BrowserSkill.git
cd BrowserSkill

From there, I would follow the repository’s setup instructions and connect the extension to the local CLI. My preferred workflow is to keep the agent’s browser actions explicit and inspectable:

{
  "browserAutomation": {
    "enabled": true,
    "requireConfirmationFor": [
      "form_submit",
      "file_upload",
      "payment",
      "account_changes"
    ]
  }
}

The real productivity win is not “AI can click buttons.” It is that an agent can handle repetitive web tasks inside the environment I already trust: checking dashboards, collecting information from authenticated tools, reproducing UI issues, or filling routine forms without forcing me to abandon my current browser session.

The extension boundary is also a healthier design choice than handing an agent unrestricted remote-control access. I can see what is happening, stop it, and keep the interaction close to the browser.

A few things I would watch before using it in production:

Treat the active browser session as sensitive. Limit which agents can invoke browser actions and avoid leaving privileged tabs open.
Add confirmation gates for destructive actions, uploads, purchases, and messages. Fast automation is useful; silent mistakes are not.

The project’s recent community signal—29 new stars today—makes sense to me. BrowserSkill is not flashy for the sake of it; it solves the awkward gap between AI agents and the logged-in browser we already use. That practical focus is exactly why it feels so promising.