From Zero to 1.5 Million Impressions: Open-Sourcing All My Software, Skills, and Local Agent Workflows

Hey everyone, I’m Joseph Zhou. Today I’m going to share how I set up my local tool stack to develop and ship multiple projects in parallel.

But before getting into the specific software and workflows, I want to share one idea first: in an age of extreme attention scarcity, visual presentation matters more than your product’s features.

📌Note to my English-speaking friends: Today’s post is a full workflow breakdown written mainly for the Chinese community. I’ll keep sharing my daily builds in English as usual! (If you’re curious about my local agent stack, X’s auto-translate actually works pretty well on this one.)

As a founder and creator (most of the time these two roles overlap), how do you get people to see your work? How do you get them to pay attention to it? I’ve seen too many great products fade into obscurity because their marketing visuals just weren’t eye-catching enough.

To be fair, many top engineers look down on this kind of showmanship. But as a startup founder based in Shenzhen, the exposure I get on social platforms is far more than vanity for me — it’s how I’ve met a lot of new people, and that’s been incredibly helpful.

I’d even go so far as to say: for a startup, the founder’s social media presence is an asset on par with product quality.

True to my belief in sharing and open-sourcing everything I build, today I’m going to hold nothing back — the software, the skills, and all of my workflows, shared in full.

I officially started posting content on October 12th. Back then, on both X and Xiaohongshu, I was starting completely from scratch.

Here’s where things stand after these twenty-odd days. It may be a drop in the bucket next to big influencers, but for a creator doing a cold start, it’s a pretty solid opening:

• X (Twitter): 1.7M+ impressions / 3,000+ followers

• Xiaohongshu: 1,000+ followers / 12K likes (frequently throttled due to the well-known no-external-links policy)

• WeChat Official Account: 2,000+ followers

X analytics: 1.7M impressions, 15,500 likes

X analytics: 1.7M impressions, 15,500 likes

Every single post I published this month was created independently by me. Being a creator on social media these days takes far more effort than being a “blogger” who just translates and reposts.

So how exactly does my local development environment fit together and get configured? How does an “idea” turn into something actually ready to publish?

Workstation Overview

Frontend Design: From Design References to Dynamic Pages

Let me walk you through the most important kind of work — frontend design — starting with how the cinetty Skill, which generates TUI architectures in one command from the terminal, came to be.

All the design references I collect day to day are organized in Eagle; it’s my favorite file manager so far. When I need ready-made page sections or motion components, I pull them from framesbase (a frontend asset library) and Motion+ (a motion library — you can find them directly on Xianyu).

Since my main agent always carries this accumulated design knowledge and my personal standards with it, I don’t have to re-explain my preferred style from scratch every time we start on an interface.

In this design pipeline, Paper MCP @paper is a crucial tool — the agent can read and write the design canvas directly.

Take my hardware product site as an example: I don’t have the agent jump straight into writing frontend code. Instead, I first have it produce several different prototypes side by side on the Paper canvas. I pick one, then iterate on it three rounds, gradually refining the design until I’m happy with it.

Paper handles the static design phase. Once the static screens are fully locked in, I use motion libraries like Motion — combined with components from framesbase and Motion+ — to turn the frozen design step by step into a dynamic, truly interactive page. Lock in the static design first, then build the dynamic interactions — two distinct phases, each refined separately.

For the cinetty promo video, for instance, the first version started as individual storyboard frames built in Paper and revised gradually.

You can see just how many versions the cinetty promo video went through.

When actually working through interface design, I also assign the agent the right design skills for the task. At the polish stage, Jakub Krehel’s interfaces skill set comes in handy — great for comparing multiple UI variants or running item-by-item interaction, UI copy, and accessibility checks.

For dedicated product landing pages, I pair it with Elaya’s ai-design-skills, which helps organize the landing page’s content structure and turn finalized static designs into dynamic presentations.

Existing project conventions and personal standards don’t get overwritten by generic templates. The methods are just helpers — what to adopt or drop is still my call.

To put it bluntly, my rule is simple: the tool stack guarantees the floor, personal taste determines the ceiling, and the agent’s taste follows the human’s taste.

As for how I gradually build up aesthetic sensibility day by day — that’s too big a topic; I’ll save it for another post.

Feature Development: Orchestration via the Main Conversation and Multi-Model Division of Labor

For feature development, my primary environment is Claude Code, with the main agent running Claude Opus. Day to day, I hand my ideas and requirements straight to the main agent (Opus 5.5 high), and it doesn’t write code itself — it steps back to maintain a global view, responsible for breaking down tasks and coordinating progress.

I’m using a self-built Claude desktop client, which works seamlessly alongside my own tool stack.

Different models are assigned to development tasks based on their strengths: GPT (Codex) handles implementation and independent code review; Claude and Gemini both handle UI and visual work.

For tasks that need clarifying thought processes and driving engineering forward, I use Matt Pocock’s skill set — useful for clarifying requirements, splitting up tasks, and doing follow-up diagnostics and code reviews. For cross-phase planning, I switch to pstack, letting it handle overall planning, architectural judgment, phase retrospectives, and work-context handoffs when shifting gears.

Day-to-day engineering execution, code review, and feature verification are pushed forward by the agent on its own according to established requirements — I don’t need to stop and ask at every step. We also schedule independent reviews per task to check whether the code meets project standards and the original requirements, and verify that features actually work through real operation.

This is paired with an agent browser that has login sessions, and I also recommend the open-source egolite. The agent can operate web pages directly, run through real user flows, and show me the page results.

Next to my desk sits a second MacBook Air, reserved exclusively for the agent to do real-device keyboard, mouse, and UI operation testing — keeping its interface verification completely separate from the work on my primary machine, so they never get in each other’s way.

For me, a product only truly matters once it’s live and being used in real-world scenarios. Engineering checks and verification are handed off to the agent — I spend the energy I save on design taste and product judgment: whether the design matches the original intent, whether I’m personally satisfied with the visuals. These key calls stay with me.

Multi-Project Management: One Main Conversation and a Shared Workbench

I usually have several projects in development at once. Back when I was still working in the terminal, I had to keep track of each project’s progress in my head, bouncing between a pile of conversation windows and asking for status one by one.

The design of Grok Bot — a single main conversation that quietly coordinates other threads behind the scenes — inspired me. Now I only ever deal with one main conversation in daily work, and I built my own desktop client for Claude Code that turns the originally command-line-driven interaction into an experience close to that of a personal agent.

The reason this single entry point works so smoothly comes down to continuous collaboration: it increasingly understands my standards. My preferences in work, project conventions, aesthetic leanings, and the accumulated work history all keep building up through daily collaboration — nothing restarts from zero when I switch tasks.

Achieving that continuity took a lot of behind-the-scenes engineering effort on my part. These accumulated records and knowledge bases mean many things don’t need to be repeated over and over.

A single main conversation isn’t enough on its own. When multiple project lines are advancing simultaneously, everyone has to be working from the same source of truth. I use Linear as that shared basis for work. My own words, decisions from discussions, the specific tasks broken out, phase progress, and the verification evidence handed back at the end — all of it lives in Linear issues.

Linear works beautifully as the orchestration layer, syncing status and context per Issue, and it’s ideal as the channel for handing evidence back for review.

Working off the issues as the basis of record, whenever something changes on that end, the main agent receives it and proactively picks up where things left off.

Content Research and Publishing: Community Tracking and Recording for the Archive

Once the product and pages are polished to a good degree in the workbench, the content research and publishing line is running in parallel.

I use @bot to keep an eye on what’s happening on X, tracking the topics I care about and pinging me at the right moments.

Before each post goes out, I have Grok research the topic first — what people are discussing, who’s involved, which posts are performing well — and after the post is published, I have it review how it actually did. Along the way, Gemini also handles copywriting and video understanding tasks.

I keep groki on my desk, so I can assign tasks by voice to the little robot on my desk and hear it read the responses back — no need to switch back to a particular chat window to pass instructions along to the agent behind it, or to catch up on community activity at any time.

JosephZhou@openmys·Oct 18Groki (ESP32-powered Grok bot hardware) just got an epic update!!! X bloggers now have a 24-hour desktop assistant!

Groki can now directly invoke your @bot’s native voice features. No third-party voice relay API needed — just use the voice quota included with your Grok subscription.

Native voice control for all of the Bot’s tools — creating new Bots, setting scheduled tasks, invoking X tool useShow moreQuoteJosephZhou@openmys·Sep 261:06Groki Bot: a desktop body for Grok Bot. Hardware: M5Stack CoreS3 (ESP32-S3)

• Touch it, and it reacts with emotions.
• Control Grok Bot by voice. Anything you’d ask it in the app, you can just say out loud.
• It turns to follow your face as you move. Watch it work: I ask out212617321K

My ESP32 development workflow

My ESP32 development workflow

And before an idea finally becomes a finished product people see on X, the last step is recording and organizing. Whether it’s capturing demo footage of completed work or producing videos for external release, we use Screen Studio and CleanShot for screen recording and screenshots.

Screenshots, recordings, and final deliverables all get archived back into Eagle, becoming accumulated material the next round of creation can draw from directly. Whether a finished video or piece of content actually gets published still comes down to me looking it over and deciding.

Daily Operations: Keeping Your Attention on What You’re Doing

Finally, back to the day-to-day right at hand. Beyond the screen and little robot mentioned earlier, I also keep a Stream Deck and my usual Logitech mouse on my desk.

Both the Stream Deck and the Logitech mouse are devices I’m very comfortable with, but they have substitutes. What really matters is being able to turn a set of frequently repeated actions into shortcut operations you can reach for without thinking.

Attention is precious. Every time you stop to hunt for a button, switch interfaces, or repeat an operation, it interrupts the thought you’re in the middle of. I use these devices because I want to spend less attention operating tools and keep it on creation.

Closing Thoughts

Of course, this workflow is itself a “work in progress” that keeps iterating. Whenever I hit a new pain point in daily development, I’ll casually write a new tool or rework a piece of the process — I iterate on my own friction.

The best tool stack is always the one built around your real workflow.

Going forward, as several of my new products officially launch, and as I share more concrete methods for building aesthetic sensibility, I’ll keep sharing them without holding anything back. If you found this useful, consider giving me a follow — let’s move forward together.