AI Agent | Attack on Life

How to Use Claude (Step-by-Step Guide)

Thu, 25 Jun 2026 07:30:53 +0800

This Claude guide collects practical usage methods and tips to help users better understand and use Claude.

Clear chat history

Note: Claude currently does not provide a one-click option to clear all history. You can only select and delete conversations page by page.

What Is Multica? Why I Built an iOS Client Called Multica Go

Fri, 12 Jun 2026 10:30:00 +0800

I have been using Multica for a while now. After going through Skills, MCP, and Claude Code, I increasingly feel that Multica’s product model of “treating agents as colleagues” is the direction that can actually land and run today. The more I use it, the more I notice a real mobile need. The core requirement is similar to using Codex or Claude on mobile: I want to keep working with AI in mobile scenarios. I checked and found that the official iOS app had not been released yet. I also tried the self-hosted mobile experience, but it did not fully meet my needs, so I built an unofficial client called Multica Go. It is now available on the App Store.

This post first explains what Multica is and why it is worth using, then talks about Multica Go.

What Is Multica?

In one sentence: Multica is an open-source Managed Agents platform that turns coding agents such as Claude Code, Codex, Gemini, and Cursor Agent into real teammates you can assign tasks to.

Its core idea is:

Your next batch of employees will not be human.

That may sound a little exaggerated, but after using it for a while, you realize it is not just marketing copy:

Agents have their own avatars and identities. They appear on boards, join comments, and proactively report blockers.
You assign an issue to an agent just like assigning it to a colleague. It takes over, writes code, opens PRs, and posts progress updates.
You do not need to copy and paste prompts every time, and you do not need to stare at the terminal while it runs.
Agent “experience” is accumulated into Skills, which all agents in the team can reuse.

What Problem Does It Solve?

If you already use Claude Code or Codex to write code, you probably know these pain points well:

Context loss: every new window requires you to explain the project background again.
Missing task management: what ran, how it went, and who should follow up all depend on memory.
Multi-agent switching is tiring: Claude Code is better for one task, Codex is better for another, and manually switching is fragmented.
Repeated work: the same deployment, migration, or review process has to be taught to each agent again in every project.

Multica productizes this workflow:

Issues are first-class citizens: every task exists as an issue, with status, comments, and a timeline.
Agents are teammates: when assigning an issue, agents appear in the assignee dropdown alongside human members.
Squads route work: as the team grows, you can assign a task to a squad led by a leader agent, and the leader decides who should handle it. @FrontendTeam is more stable than @Alice or @Bob or @Charlie.
Skills are reusable: each solved problem can become a skill, so the next run starts from that experience instead of from zero.
Autopilots: scheduled tasks triggered by cron or webhooks let agents run daily reports, weekly reports, code inspections, and other recurring work by themselves.

Architecture and Tech Stack

The backend is written in Go and the overall structure is clean:

┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Next.js │────▶│ Go Backend │────▶│ PostgreSQL │
│ Frontend │◀────│ (Chi + WS) │◀────│ (pgvector) │
└──────────────┘ └──────┬───────┘ └──────────────────┘
 │
 ┌──────┴───────┐
 │ Agent Daemon │ running on your own machine
 └──────────────┘

The supported agent CLI matrix is broad: Claude Code, Codex, GitHub Copilot CLI, OpenClaw, OpenCode, Hermes, Gemini, Pi, Cursor Agent, Kimi, and Kiro CLI.

How to Get Started

Read the official website.
Read my previous self-hosting guide as a supplement.
If you still have questions, read the official repository source code.

As mentioned at the beginning, I have a strong need on mobile. I want to browse the inbox, reply to comments, change statuses, and especially create issues on my phone as naturally as using the GitHub iOS app. That is why Multica Go exists.

What It Is

An unofficial iOS app, rebuilt natively with SwiftUI. Its experience and features come from the official web app and my own real usage needs.
Its name is Multica Go.
Key differentiator: custom server addresses. It can connect to the official cloud or a self-hosted Multica instance, and it supports multiple server connections for quick switching. For example, I need to connect to three Multica services myself. It also supports voice input and richer interaction details. Of course, the core capability still depends on the Multica server APIs: the number of APIs determines the upper limit of what the app can do. The client is just one way to call them.

What Works Today

Secure token and workspace storage with Keychain
Workspace selection and switching
Inbox: list, unread styling, tap to mark read, swipe to archive, bulk mark/archive
Issues: my issue list, details, timeline, comments, status/priority/date editing, create/edit/delete
Chat: conversation list, message sending, agent task status, persisted drafts
Projects: list, details, resource management, create/update/delete
Search: global search for issues and projects
Voice input: issue comments and chat message boxes can switch to voice input, using iOS system speech recognition. It supports Mandarin and English, shows recognition results in the input box in real time, and sends automatically after recognition ends.
Internationalization: Chinese, English, Korean, and Japanese.

Still on the Roadmap

It is always on the roadmap and will keep iterating, because I am a heavy user myself and the product is driven by real needs.

Try It

Multica Go is now available. If you are interested, you can try it here:

👉 https://multica.1991421.cn/

Final Thoughts

Multica is one of the tools I have been least willing to put down recently. It is not just another AI wrapper. It turns “AI collaboration” into a real product shape, with boards, issues, squads, and accumulated skills. Combined with being fully open source and self-hostable, it is very friendly for individual developers and small teams.

As for Multica Go, it is my product-minded vote for Multica. If you also use Multica and are not fully satisfied with the official app, try the TestFlight build and feel free to send feedback.

Multica official website: https://multica.ai
Multica docs: https://multica.ai/docs
Multica GitHub: https://github.com/multica-ai/multica
Multica Go entry: https://multica.1991421.cn/
My previous post: Understanding Multica: Self-Hosting Guide

What Is Multica? Multi-Agent Collaboration Platform Guide

Tue, 26 May 2026 14:50:09 +0800

I have been using Multica more recently. This article records what I currently know and understand about Multica.

What Is Multica?

Official description: The open-source managed agents platform. Turn coding agents into real teammates - assign tasks, track progress, compound skills.

Multica is not an AI model, and it is not another AI chat tool. It is an AI team collaboration platform built around Human + Agent Team workflows.

You can think of it this way: it connects AI coding CLIs such as Claude Code, Codex, OpenCode, and OpenClaw into one unified project collaboration flow, so agents can be assigned tasks, execute them, report progress, expose blockers, and turn reusable experience into Skills like team members.

What Problems Does Multica Solve?

1. There are many AI CLI tools, but no unified entry point

Claude Code, Codex, OpenCode, OpenClaw, and similar tools are already powerful, but they are still separate CLIs. They are fine for temporary personal use. Once the number of tasks grows, several questions appear:

Which task was assigned to which agent?
How far has the agent progressed?
Is anything blocked?
Where do I see the result?
How do I reuse the experience next time?

Multica’s value is that it puts these CLI agents behind one unified entry point, so they work around Issues instead of being scattered across terminal windows.

2. Agent execution needs to be visible, traceable, and takeover-friendly

When using an AI CLI alone, the human often has to watch the terminal and wait for results. Multica moves task execution into a web UI, so agent status, output, blockers, and results are all visible.

This is also useful for personal project management. In many cases, what I lack is not a smarter model, but a workbench that can manage multiple AI execution tasks at the same time.

3. Prompts and experience should be captured, not rewritten every time

Much AI usage experience is hard to reuse if it only exists as prompts. For example:

How should frontend design reviews be done?
How should an SEO audit be done?
How should releases follow team conventions?
How should a complex task be split into executable steps?

This is where Skills become valuable in Multica. A Skill is not just a prompt bookmark. It captures the method, context, constraints, and workflow for a type of work so agents can reuse it in future tasks.

4. MCP lets agents connect to real business systems

An agent that only writes code is not enough. In real work, agents often need to read Figma, query TAPD, inspect GitHub, call internal systems, search the web, and read documentation.

MCP turns those external systems into tools that agents can call. Once Multica is combined with MCP, an agent is no longer just something that can talk and write code. It can enter existing workflows.

Core Concepts Behind Multica

Multica looks like a web platform on the surface, but its real value is combining several AI engineering capabilities.

Workspace / Issue / Agent

Multica puts AI agents into a project-management-like structure:

Workspace manages a project space.
Issue represents a clear task.
Agent is the executor that can be assigned.
Runtime shows where the agent runs.
Daemon makes the task actually execute.

This structure turns AI execution from “I asked something in a chat window” into a stateful workflow with records and collaboration entry points.

Runtime

Runtime is the environment where tasks actually run. It can be your local computer or a server.

Multica itself is not a model platform that completes every coding task for you. It is more like a scheduling and collaboration layer that assigns tasks to available AI CLIs on a Runtime, such as Claude Code, Codex, OpenCode, and OpenClaw.

Daemon

Daemon is the connector between Multica and Runtime.

It runs on the machine, discovers AI CLIs available in the local PATH, registers the Runtime, receives tasks assigned by Multica, starts the corresponding agent, and reports status, logs, and results back to Multica.

So many problems are not really caused by the Multica web app. They come from the daemon not running, PATH not detecting a tool, or the local AI CLI not being configured correctly.

MCP

MCP can be understood as the protocol layer that lets agents connect to external tools and business systems.

For example, Figma MCP, TAPD MCP, GitHub MCP, and Firecrawl let agents read designs, query project-management systems, access code platforms, and scrape web content. Without MCP, agents usually work only with local code and chat context. With MCP, they are closer to executors that can participate in real workflows.

Skills

Skills are a key layer in this kind of Multica setup.

MCP answers “what tools can the agent call”. Skills answer “how should the agent complete this type of task”. Frontend design, mobile design, SEO audits, code review, release processes, and internal standards can all be written as Skills.

This is also what I mean by “experience reuse”. Instead of rewriting a long prompt every time, you turn a stable method into a Skill and let agents load that capability when appropriate.

Product Form and Licensing

Multica’s iteration progress

The official team uses Multica itself to manage Multica development, so the iteration speed is very fast and the product keeps improving.

This is the standard case of using AI to build AI.

Current Multica clients

PC web
iOS app not released
Desktop app

Open source and licensing

Yes. You can self-host it, and the code is public. However, Multica uses a modified Apache 2.0 license, not a completely unrestricted Apache 2.0 license.

In simple terms, internal organizational use and internal enterprise deployment are generally OK. But if you want to wrap Multica as a SaaS, hosted service, or part of a commercial product sold to third parties, you need to check its commercial license restrictions. Also, when using its frontend, you cannot freely remove or modify the logo and copyright information in the console.

So it is suitable for personal use, internal team pilots, and private company deployments. If you want to package it commercially for external users, you need to confirm the license separately.

What You Need Before Using Multica

Skills
- For example, firecrawl and tgit (Tencent Gongfeng)
MCP
- For example, TAPD MCP and Figma MCP
Experience with AI CLI tools such as Claude Code, Codex, and OpenCode
Prompts

Multica itself is not magic. The prerequisite for using it well is that you are already reasonably comfortable with AI CLIs and know how to split work into task sizes that agents can execute.

My own experience is: the clearer the task, the better Multica works. The more vague the task, the more it eventually returns to a human to add context, split steps, and define acceptance criteria.

Recommended Skills

superpowers
ui-ux-pro-max-skill
frontend-design
mobile-ios-design
seo-audit
find-skills

Skill stores

https://www.skills.sh
GitHub
https://skillhub.cn
- Offline installation is recommended

Self-Hosting Flow

This section follows the order of a complete self-host setup: prepare the server and backend first, then configure access URLs, AI CLIs, daemon, and token.

1. Server requirements

Docker
Git

2. Install Multica Server

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server

docker compose -f docker-compose.selfhost.yml -f docker-compose.selfhost.build.yml up -d --build

# If compose is not supported
yum install -y docker-compose-plugin

3. Install Node.js

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.4/install.sh | bash

nvm install 26

4. Configure domain and Caddy

If you want external access, I recommend installing Caddy. If you only need LAN access, you can skip Caddy and directly visit http://localhost:8080.

Point your domain DNS to the server IP, install Caddy, and add the following to /etc/caddy/Caddyfile:

yourdomain.com {
 reverse_proxy localhost:8080
}

Then restart Caddy:

systemctl restart caddy

5. Configure AI tools

Common options include:

codex
opencode
claude code
openclaw
codebuddy
and others

After configuring a new AI tool, if Multica cannot detect it, run multica daemon restart to restart the daemon. Among the tools above, I mainly use codex and opencode for now.

6. Configure Daemon

multica setup self-host --server-url https://xxx --app-url https://xxx

For LAN access, you can directly use http://localhost:8080. For external access, use your domain URL. For example, because my Multica server and daemon are on the same machine, I can just use the defaults.

7. Create a token and log in to the CLI

Create a token in settings, then run:

multica login --token xxxx

Common daemon commands:

multica daemon status
multica daemon start
multica daemon restart

# For abnormal issues, check logs
vi /root/.multica/daemon.log

8. Confirm default frontend and backend URLs

Frontend: http://localhost:3000
Backend: http://localhost:8080

Common Issues and Pitfalls

1. daemon cannot detect AI CLIs

If you installed Codex, Claude Code, OpenCode, or similar tools but Multica cannot detect them, the daemon’s startup PATH probably does not contain those commands yet.

First confirm in the terminal:

which codex
which opencode

Then restart the daemon:

multica daemon restart

If it still fails, check daemon logs.

2. Rebuild or restart services after modifying env

Some self-host settings come from .env. After modifying env values, do not just refresh the page. You need to rebuild and restart the service.

docker compose -f docker-compose.selfhost.yml up -d --force-recreate backend

View logs:

tail -f daemon.log

After self-hosting, you need to log in to the web app first, create a token in settings, then run this in the CLI:

multica login --token xxxx

If no email service is configured, you may need to check the backend logs for the verification code. This is an easy place to get stuck during the first deployment.

4. External access needs HTTPS and domain handling

LAN access can use localhost directly. For external access, I recommend Caddy so HTTPS, reverse proxy, and DNS are handled cleanly.

5. Skills and MCP do not become useful just because they are installed

Skills and MCP are capability layers. The final result still depends on whether the task description is clear, whether there is enough context, and whether acceptance criteria are explicit.

My suggestion is to start with small tasks: fix a clear bug, run an SEO check, or adjust a component style. Then gradually expand to more complex tasks.

6. agent finished without creating an issue

This means issue creation failed. Possible causes include insufficient AI quota or an expired login. Since the error happens during issue execution, you can inspect the issue details or execution logs. However, errors during the issue-creation stage are currently not shown very directly, so when you encounter this, retry or switch agents.

7. AI-generated attachments

In Chat mode, attachments currently cannot be surfaced directly; clicking download reports an error.
In Issue mode, tests show that asking AI to generate attachments in comments works, but adding attachments directly to issue content does not.

This is how the current Multica version behaves. Future versions may fix it. For now, use the workarounds above.

8. Tasks cannot continue because of insufficient AI quota or similar exceptions

You can use automation to query regularly as a compensation mechanism. Since an agent has permission to fetch all issue information, it can scan on a schedule, and when it finds this kind of state, post a comment. Triggering the agent again through a comment can continue processing.

Operations and Upgrades

Check the current version

Update AI CLIs

For example, when updating Codex or Claude Code, you do not need to log in to the target machine manually. You can update them directly through the Multica runtime.

Upgrade Multica

docker compose -f docker-compose.selfhost.yml pull

docker compose -f docker-compose.selfhost.yml up -d --force-recreate

# Upgrade daemon
multica update

Further Understanding

The Three Basic Roles in Agent Collaboration

The essence of AI agent team collaboration can first be split into three roles: coordinator, worker, and verifier.

This view comes from Multica’s author.

The coordinator is responsible for “what to do”: understanding the goal, breaking down tasks, creating a plan, and deciding who should handle each task.

The worker is responsible for “how to do it”: executing concrete tasks based on context, such as writing code, researching, changing configuration, or generating documentation.

The verifier is responsible for “whether it was done correctly”: independently checking whether the result meets the requirements, then sending feedback back to the coordinator or worker for another iteration if needed.

Multica’s value is that it does not just let one agent execute isolated work in a chat window. It puts these roles into a manageable, traceable, and reusable collaboration flow.

Understanding Multica Through Its Source Structure

From the source-code perspective, Multica is not a simple Next.js project, nor is it a small tool that only starts CLIs. It is more like a monorepo: frontend, backend, desktop, mobile, shared packages, and deployment scripts are all in one repository, combined through a pnpm workspace and a Go server.

The repository can roughly be understood like this:

multica/
├── apps/
│ ├── web/ # Web console, Next.js App Router
│ ├── desktop/ # Desktop app, Electron
│ ├── mobile/ # iOS mobile app, Expo + React Native
│ └── docs/ # Documentation site
├── packages/
│ ├── core/ # Shared frontend business capabilities: API, issues, agents, skills, runtimes, etc.
│ ├── ui/ # Shared UI components
│ ├── views/ # Reusable view layer
├── server/
│ ├── cmd/ # Go entry points, including server / CLI / daemon commands
│ ├── internal/ # Backend core business implementation
├── deploy/ # Helm and deployment configuration
├── docker/ # Docker-related configuration
├── scripts/ # Install, build, and helper scripts

The most important parts are these three layers:

apps/web is the collaboration UI. Users create Issues, configure Agents, view Runtimes, manage Skills, and inspect execution logs and status there. It does not directly execute AI tasks. It talks to the backend through APIs and WebSocket.
server is the scheduling and state center. The README also makes it clear that the backend is written in Go and uses Chi, WebSocket, and PostgreSQL/pgvector. Objects such as Issue, Workspace, Agent, Runtime, Autopilot, and Skill eventually land in backend data models and task lifecycles.
multica daemon is the execution layer on the machine. It detects Claude Code, Codex, OpenCode, OpenClaw, and other CLIs in the local PATH, registers the Runtime, polls for tasks, creates isolated working directories for tasks, starts the corresponding CLI, and reports output and status back to the server.

So one agent task roughly follows this path:

Create Issue in Web
 -> server stores the task and assignment
 -> daemon registers Runtime and polls executable tasks
 -> daemon starts the corresponding AI CLI in a local working directory
 -> AI CLI modifies code, outputs logs, and reports progress
 -> daemon sends status and result back to server
 -> Web shows progress, blockers, and results in real time

packages/core is also worth noting. It is not just a normal utilities collection. It extracts shared frontend business concepts such as agents, issues, runtimes, skills, workspace, realtime, and permissions. Web, Desktop, and Mobile therefore do not need to reimplement the same business access logic separately.

That is why Multica’s source structure matches its product positioning: apps/web handles the human-agent collaboration UI, server handles state, permissions, and task scheduling, daemon connects to the real execution environment, and packages/core lets those business concepts be reused across clients. Once you understand this layer, terms like Runtime, Daemon, Issue, and Skills stop being product labels and start mapping to real source-code boundaries.

Use Multica to standardize AI SOPs

Example scenario

Receive bug
 ↓
Analyze cause
 ↓
Modify code
 ↓
Run npm test
 ↓
If it fails, continue fixing
 ↓
After passing, git commit
 ↓
push
 ↓
Create PR
 ↓
Notify you for review

What role does Multica play here?

Multica itself is not the SOP.

It is more like:

the platform that executes AI SOPs.

In other words:

SOP = recipe Multica = kitchen Large models (Claude, Codex, GPT) = cooks

Without a recipe, the result may differ every time.

With an SOP plus Multica, AI can execute through a fixed process.

OPC (One Person Company)

OPC (One Person Company)
 │
 ▼
 Needs an AI team
 │
 ▼
 Multica
 │
 ▼
Multiple AI agents + multiple models + various tools

Final Thoughts

My feeling is that Multica is a platform for connecting AI coding agents to project collaboration workflows. It is not a new AI technology product by itself, but a product assembled from AI technologies. Whether for personal project management or team R&D collaboration, Multica is suitable for managing a batch of executable AI-agent tasks: split requirements into Issues, assign them to different Agents, track progress, inspect blockers, and turn stable practices into Skills.
Have fun with it.