mirror of
https://gh-proxy.org/https://github.com/klinsmaya/multica.git
synced 2026-11-11 02:46:45 +08:00
苗大
e13a902f59
* chore(docs): upgrade to Fumadocs 16 and Next.js 16 Fumadocs UI 16 requires Next.js 16, so the docs app moves to Next 16 alongside it (apps/web is already on 16). - fumadocs-core/ui 15 -> 16, fumadocs-mdx 12 -> 15 - import collections from .source/server and RootProvider from fumadocs-ui/provider/next - migrate UI translation keys to the v16 message ids - rename middleware.ts to proxy.ts per the Next 16 convention - declare the status, diff and overlay color slots v16 moved out of preset.css - keep heading anchors, now rendered as a[data-card], out of the card styles - drop the language select v16 adds to the sidebar footer; the docs settings menu already switches language * feat(docs): add a kit for click-through product demos Docs pages can embed small demos that imitate the product and walk the reader through one action. The kit holds the shared frame (title, replay, live caption), the coach mark that rings the next control with a localized "Click" and an arrow, and timeline pieces for runs, comments and steps. Demos start when scrolled into view, take their scenario copy per locale, and isolate their stacking so they stay under the page header. tw-animate-css provides the enter animations, as in apps/web. * fix(docs): consistent Steps, Tabs and Accordion styling - a Steps item is at least as tall as its number badge, so one-line steps don't stack their badges - accordion headers (not-prose h3) skip the editorial heading styles - hide the copy-link button Fumadocs adds beside accordion titles; the ids stay so links still open an entry - tab bars end in a hairline that carries the active underline without overflowing the scrolling bar, and a lone code block in a tab keeps its inset and border, so every tab group looks the same * docs: interactive getting-started pages - concepts: clickable map of the core objects and their relations - how-multica-works: step-through of one run from issue to result - triggering-agents: pick a goal, get the way to start an agent, including issue wakeups - cloud-quickstart and tutorial use Steps; agent creation, the runtimes entry and the sidebar paths match the current product Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive workspace, issue and project pages - demos for member roles, issue statuses, project progress, workflow handoffs, creating an issue with an agent, deliverable versions and local directory modes - new Analytics page with a demo of the usage and errors tabs: cost estimates, runtime usage, custom prices and per-issue spend - issues: custom properties, display settings and saved views, peek, bulk edits and duplicates - project progress counts the done and closed categories; status category names, the workflow return label and share links follow the product; agent moves trigger handoffs too - project-resources: modes as Tabs, worktree details as Accordions Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive agent pages - demos for agent Access, creating an agent, adding a skill and a squad run led by its leader - agents-create describes the current runtime -> configure -> done flow instead of the removed start-blank / build-with-AI choice, and covers workspace-shared MCP servers - squads: notified members, a three-column re-trigger table, and the sections the ja/ko pages were missing Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive everyday-collaboration pages - demos for steering a running agent, mentioning an agent, assigning an issue, resolving a thread, running a quick action, chat, the chat message queue and the inbox - mentioning-agents documents steering and the per-recipient delivery options; follow-ups no longer always wait for the run to end - comments: sub-issues created from a thread, the thread minimap and edit-conflict comparison - chat: the floating window, draft restore and the message queue - new page for search, keyboard shortcuts and preferences - quick actions: the sidebar list is not filtered by invoke permission Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive runtime and automation pages - demos for a failed run and its retry, a run waiting on an offline computer, an autopilot run, an issue wakeup and picking a coding tool - new Issue wakeups page: event, time and periodic conditions, check-ins, limits, the child_done system rule and its workspace default, and the `multica issue wakeup` commands - daemon-runtimes: start at login, local MCP merging, cleanup and retention, Codex memory defaults, and sharing a runtime with specific members - runs on an offline runtime fail only after the reconnect grace (default 3h); the execution log lists the latest three past runs - providers and the install guide add ZeroClaw and the model-selection column; install-agent-runtime uses Steps, Tabs and per-tool Accordions - the event-filter heading keeps the anchor the product links to Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: interactive integration and app pages - demos for talking to a channel bot, a merged PR completing its issue and per-workspace desktop tabs - the bot guides share one Steps-based layout with their old anchors - Lark and Telegram attach recent group messages as read-only context - desktop-app: pinned tabs - fix stale French GitHub and mobile self-hosting sections, and the compressed ja/ko Telegram pages Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * docs: restructure self-hosting and reference pages - self-host-quickstart and troubleshooting use Steps, Tabs and Accordions with ASCII ids so links open the right entry; code-block tabs become Tabs like everywhere else - environment-variables adds the GC, log rotation and per-tool path/model settings and drops the unused MULTICA_KEEP_ENV_AFTER_TASK - cli adds issue timeline, issue wakeup, daemon autostart and the commonly used flags - fix a corrupted link, flattened code indentation and dead anchors - translations no longer call GitHub issues "tasks" Covers en, zh, ja, ko and fr; copy edited to drop template phrasing. * feat(docs): show the search bar with compact results The site already served a per-locale search index from /api/search (with character-level tokenizers for zh and ja), but the layout hid Fumadocs's search toggle, leaving ⌘K as the only, undiscoverable way in. The toggle is back: a search bar atop the sidebar on desktop and an icon in the mobile header. Fumadocs's default dialog renders every matching paragraph, table and row in full, which buries the page titles. Like DocSearch and Pagefind, results now show the page and section titles plus at most three matches per page, each a two-line excerpt around the match; table rows become one line with their cells joined. The index and ranking are unchanged.
425 lines
25 KiB
Plaintext
425 lines
25 KiB
Plaintext
---
|
|
title: Complete tutorial
|
|
description: "Start from an empty workspace and walk a personal website project through all of Multica's core flows: creating agents, delivering with issues, forming a squad, building skills, and setting up automation."
|
|
---
|
|
|
|
import { Step, Steps } from "fumadocs-ui/components/steps";
|
|
|
|
Multica is a platform where people and AI agents work together. This tutorial starts from nothing and covers:
|
|
|
|
- setting up a workspace of your own
|
|
- collaboration between people and agents, and automatic collaboration between agents
|
|
- handing repetitive work to automation
|
|
- turning what works into skills, and iterating on your agents over time
|
|
|
|
The example project is a personal website, used to walk through Multica's overall flow and core features end to end.
|
|
|
|
**Before you start:**
|
|
|
|
- A Multica account (sign up at [multica.ai](https://multica.ai))
|
|
- A computer with at least one AI coding tool installed and signed in, for example Claude Code or Codex. The full list of supported tools is in [Install AI coding tools](/install-agent-runtime).
|
|
|
|
## Create a workspace
|
|
|
|
A workspace is where a team works: issues, projects, and agents all belong to one. The onboarding after sign-up walks you through creating your first workspace. If you were invited to a team, signing in takes you straight into that team's workspace.
|
|
|
|
This tutorial creates a new workspace for the walkthrough.
|
|
|
|
<Steps>
|
|
<Step>
|
|
|
|
Click the workspace name at the top of the sidebar and choose **Create workspace**:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Fill in two fields:
|
|
|
|
- **Name**: shown to members; it can be changed later.
|
|
- **URL**: the slug in the workspace address — the `my-team` in `multica.ai/my-team`. It cannot be changed after creation.
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Creating it opens the new workspace. The sidebar on the left is where every later step starts; the issue list in the middle is still empty, and the next few steps get agents to fill it.
|
|
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Connect your computer
|
|
|
|
Agents execute work on the computers you connect, using the AI coding tools installed on those computers.
|
|
|
|
This tutorial uses [Multica Desktop](https://multica.ai/download): after downloading and signing in, it registers this computer as a runtime automatically and detects the installed AI coding tools. Open **Runtimes** under **AI Team** in the sidebar and confirm the computer is online:
|
|
|
|
|
|
|
|
Open the computer to see each detected tool:
|
|
|
|
|
|
|
|
Desktop is not required: on the Runtimes page, click **Add**, choose **Other machine or server**, and follow the prompts to install from the command line. The daemon then runs in the background — see [Daemon and runtimes](/daemon-runtimes).
|
|
|
|
## Create your first agent
|
|
|
|
Agents are full members of a workspace: they can be assigned issues, post comments, and talk with you. The first agent is a helper that handles day-to-day workspace chores; a number of later steps in this tutorial are handed to it.
|
|
|
|
Open **Agents** under **AI Team** in the sidebar and click **New agent**. First choose the runtime: one of the AI coding tools on the computer connected in the previous step; this tutorial uses Claude. Then fill in three fields on the configuration page:
|
|
|
|
- **Name**: `Multica helper`.
|
|
- **Model**: one of the models that tool supports. This tutorial uses Sonnet.
|
|
- **Instructions**: the prompt provided to the agent on every run. State what it is responsible for and what it is not:
|
|
|
|
```text
|
|
You are the helper of this workspace.
|
|
|
|
You handle what members ask for in issues and chat: create or update
|
|
issues, adjust statuses, and answer questions about what is going on
|
|
in the workspace.
|
|
|
|
Keep replies short. After finishing something, reply with a one-line
|
|
summary of what you did. Do not touch code or repositories. If a
|
|
request is ambiguous, ask before acting.
|
|
```
|
|
|
|
|
|
|
|
Leave the remaining fields at their defaults and click **Create agent**. Back on the **Agents** page, Multica helper is online and can take work:
|
|
|
|
|
|
|
|
## A second agent, created through chat
|
|
|
|
Building the site needs an engineer that can write code. This time there is no form to fill in: the workspace already has an agent, so creating the next one can be handed to it.
|
|
|
|
Open **Chat** in the sidebar, select Multica helper, and tell it to create an agent named Engineer on the same runtime, with Opus as the model, responsible for building and maintaining the personal website. Multica helper performs the creation on that computer and replies with the new agent's name and model. By default only the creator can run a new agent; leave that as is for this tutorial.
|
|
|
|
|
|
|
|
Open **Agents → Engineer** to check the result: the model is Opus, and the instructions were generated by Multica helper — scope of responsibility, how to get repository code, and requirements for submitting changes. They can be edited at any time.
|
|
|
|
|
|
|
|
## Prepare the site repository
|
|
|
|
The site's code lives in a GitHub repository. Creating and linking the repository also goes to an agent, provided this computer has the [GitHub CLI](https://cli.github.com) installed and signed in.
|
|
|
|
In **Chat**, select Engineer and tell it to create an empty repository named `personal-website` under your GitHub account (the GitHub CLI is on this computer), then register it in this workspace with `multica repo add`. Engineer creates the repository locally, registers it in the workspace, and replies with the repository address. The message did not specify visibility, so it creates the repository with the default and says so in the reply; public or private makes no difference to the following steps.
|
|
|
|
|
|
|
|
Open **Settings → Code** to confirm: `personal-website` is in the list. Agents pick a repository from here when they start runs.
|
|
|
|
|
|
|
|
Without the GitHub CLI, you can create the repository on GitHub yourself and add it manually on the same page; the result is the same.
|
|
|
|
Finally, click **Connect GitHub** on the same page and authorize the repository as prompted. Once connected, pull requests that reference an issue identifier link to that issue automatically, and PR state and CI results show up in the issue.
|
|
|
|
## The first issue: build the site
|
|
|
|
That completes the setup. From here on, this is how day-to-day work runs in Multica: requirements are written as issues and handed to agents.
|
|
|
|
The site starts from shadcn's official template: the template already brings the stack and the base configuration, and Engineer builds content and design on top of it.
|
|
|
|
<Steps>
|
|
<Step>
|
|
|
|
Click **New Issue** at the top of the sidebar (shortcut `C`). In the default agent mode there is no title to fill in: select Engineer under **Created by** and write the requirements straight into the description; the title is generated on creation. You can also switch to manual mode and write the title and body yourself. The description:
|
|
|
|
```text
|
|
Work in the personal-website repository registered in this workspace.
|
|
|
|
Start from a template instead of scaffolding from scratch:
|
|
|
|
pnpm dlx shadcn@latest init --preset b5rR41Mtnc --template next --pointer
|
|
|
|
Run the command, commit the template as-is, then build on top of it.
|
|
|
|
The site is for a photographer. It needs:
|
|
|
|
- Introduction — who I am and what I shoot
|
|
- My work — a selection of photos
|
|
- Contact — an email link that is easy to find
|
|
- Pricing — decide where a pricing table fits and how to present it
|
|
- Use placeholder images (Unsplash or picsum.photos) wherever a photo
|
|
belongs, and list where I should replace them with my own work
|
|
|
|
Design:
|
|
|
|
- Pick a style that fits a photography portfolio. It should feel
|
|
refined and understated; express that through layout, typography
|
|
and spacing, and never use words like "premium" or "high-end"
|
|
in the copy.
|
|
- Choose the fonts.
|
|
|
|
Open a pull request when it is ready.
|
|
```
|
|
|
|
The description carries three kinds of information: constraints (start from the specified template), content requirements (listed item by item), and open space (the style is left to Engineer to work out). Write the intent and the boundaries; leave the implementation to the agent.
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
After submitting, Multica creates the issue (`MUL-1`, with a generated title) and sets Engineer as the assignee. Engineer starts executing and the status moves to In Progress. The right side of the issue holds everything happening on it: status, assignee, linked pull requests, and the execution log.
|
|
|
|
The run takes a few minutes, and there are two ways into its progress: the working-status badge next to the title, and **Execution log** on the right. Open the current run:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
The execution log holds every step of the run: **Agent** rows are its own narration, and **Bash**, **Read**, and **Edit** are the commands it ran and the files it read and wrote. At the moment of this screenshot it is taking screenshots of the finished pages to check its own work, and has just found that the divider in the pricing table is misaligned. Click the ⓘ in the top right to see the computer, AI coding tool, and working directory used for the run.
|
|
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Sign-off: talk it over in the issue
|
|
|
|
When the run ends, Engineer moves the status to In Review and a notification lands in your Inbox. It posted a completion comment on the issue with screenshots of the finished pages:
|
|
|
|
|
|
|
|
Screenshots give the gist, but a review still means opening the site in a browser. The site was built on your computer, so having Engineer start a local server is enough to reach it. The **Pull requests** area on the right is also still empty; the issue explicitly asked for a PR, so ask about that directly too.
|
|
|
|
This time, use chat instead of the comment box:
|
|
|
|
<Steps>
|
|
<Step>
|
|
|
|
There is a chat button in the bottom-right corner, available on any workspace page, and it is the same feature as **Chat** in the sidebar:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Open it, select Engineer, and type `@` to reference the current issue, so the conversation carries that issue's context. Send both questions:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Engineer's reply has two parts: the local server is running, with the address to open; and the PR was in fact already submitted, but the title, branch name, and body all lacked `MUL-1`, so automatic linking had nothing to match. It then added the identifier to the PR title.
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Open the address it gave in a browser to see the site:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Back on the issue, a PR card now appears in the **Pull requests** area on the right, showing state and change size; clicking it opens the PR on GitHub. Repositories with CI configured also show check results:
|
|
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
## Write feedback into the instructions
|
|
|
|
This round of review exposed two of Engineer's working habits: it checks its own work with repeated screenshots after finishing, which takes up a lot of run time; and it opens PRs without the issue identifier, so they don't link. Both are things it will repeat every time, so what needs changing is its instructions; this issue itself can stay as it is.
|
|
|
|
You don't have to edit the instructions by hand: an agent can update its own configuration with the multica CLI. In the same conversation, give Engineer two rules: no screenshot self-checks after finishing, since review happens in a browser; and the branch name or title of a PR must carry the issue identifier. Then have it write them into its own instructions:
|
|
|
|
|
|
|
|
Engineer applies the update with `multica agent update`, adding a working-rules section to its instructions, and points out the cost of the first rule: with no screenshot self-checks, visual problems on the page are now yours to catch in the browser.
|
|
|
|
Open **Agents → Engineer**, and both rules are in the instructions:
|
|
|
|
|
|
|
|
From then on, both rules take effect with the instructions on every run. That is basically how you tune an agent: when a problem keeps recurring, write the correction into the instructions so you don't have to repeat it each time.
|
|
|
|
## A third agent: Reviewer
|
|
|
|
Engineer delivered a first version, but there are problems it cannot see itself. Review goes to a new agent: a fresh context, dedicated to checking code quality against the issue's requirements.
|
|
|
|
<Steps>
|
|
<Step>
|
|
|
|
Creation again goes to Multica helper: an agent named Reviewer, this time on Codex with the GPT-5.6 Sol model — a different tool and model from Engineer's; it only reviews and never edits code, and writes its conclusions as issue comments. The instructions are again generated by the helper — read the PR's actual state before reviewing, write findings as comments with file locations, and never modify code:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Review needs no new issue and no change of assignee. Back in MUL-1's comment box, type `@Reviewer` to mention it, write what needs doing, and send. A hint below the box says that Reviewer starts executing once the comment is sent:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
A few minutes later the review comment comes back, with the conclusion that changes are needed before merging. Five findings in two groups — three on code conventions, two on requirement conformance — each with a file and line number. The two conformance findings are exactly what Engineer could not see itself: the pricing table presents invented prices, deposits, and tax terms as real content with no placeholder marking, and the contact section carries an unverified Instagram link. The comment ends with what it verified itself: typecheck, lint, and build all pass.
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Fixing needs no new process: @Engineer in the comment box and ask it to clear all the findings. Engineer starts executing on send, visible both in the badge next to the title and in the execution log on the right:
|
|
|
|
|
|
|
|
A few minutes later Engineer reports back: all five fixed, pushed to the same PR. Both agents share one timeline, so the report only has to answer the findings one by one, with no need to restate the background:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Mention Reviewer again for a second pass: all five findings resolved, ready to merge, with two low-priority follow-up suggestions left:
|
|
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
One issue now carries two agents — Engineer implements, Reviewer reviews — and a few short comments from you keep development and review going round after round.
|
|
|
|
## Merge and close out
|
|
|
|
Merging is also issued as a comment: ask Engineer to merge the PR and make sure the issue moves to Done. It merges, deletes the branch, re-runs the checks on the merged main, and reports back. The issue status becomes Done, and a completion notification arrives in the Inbox:
|
|
|
|
|
|
|
|
That wraps up the first issue: every step from the requirement to the merge is recorded on one timeline.
|
|
|
|
## Form a squad
|
|
|
|
The MUL-1 loop works, but every hand-off started with you: mention Reviewer after reviewing, mention Engineer after the review. Coordination itself became your job, and that can be handed off too, with a **squad**: a named group of agents and members led by a leader agent. When an issue is assigned to a squad, the leader takes it: reads the issue, delegates the work, and moves the status along. When a member replies, the leader is woken automatically and decides the next step; at the end it reports the deliverable to you, which is exactly what you were doing on MUL-1.
|
|
|
|
A squad is the division of labor you already have, plus a leader:
|
|
|
|
- **Lead** (new): the leader, responsible for management: assigning work, moving the issue status along, and reporting deliverables to you, without doing the work itself;
|
|
- **Engineer** (existing): development;
|
|
- **Reviewer** (existing): reviews every PR;
|
|
- **You**: final sign-off.
|
|
|
|
Members are not limited to agents. Each member carries a one-line role description that the leader consults when delegating.
|
|
|
|
Describing this setup to Multica helper is enough: create the squad and its leader, give each member its job, attach one skill each to Lead and Engineer (covered in the next section), and put the workflow in the squad instructions — development goes to Engineer, delivery waits until the PR passes review, and Engineer merges after your sign-off. The helper applies the whole configuration in one pass with the CLI:
|
|
|
|
|
|
|
|
Open **Squads → Website Team** in the sidebar to check the result: the leader, the members, and the role descriptions are all there. Squads can also be created from a form on this page; the full mechanism is in [Squads](/squads):
|
|
|
|
|
|
|
|
## Skills: reusable methods
|
|
|
|
Writing feedback into instructions earlier only solved one agent's problem, because instructions belong to that agent alone. To share a method across several agents, or to borrow one someone else has already written, use a **skill**.
|
|
|
|
A skill is a knowledge package for an agent: one `SKILL.md` plus optional supporting files, telling the agent how to think about and handle a kind of task. Multica follows the Anthropic Agent Skills open standard, so any skill that matches the spec can be imported directly; once attached to an agent, it syncs to the runtime at execution time. Open the **Skills** page — the two skills imported above are both there, with the agents they are attached to on the right:
|
|
|
|
|
|
|
|
Opening one shows all of the skill's files:
|
|
|
|
|
|
|
|
One of these two skills is about doing the work, the other about reporting it:
|
|
|
|
- **tdd**, attached to Engineer, is an engineering method: write a failing test first, then the implementation that makes exactly that test pass;
|
|
- **i-have-adhd**, attached to Lead, is a reporting style: the first line is always an actionable next step, multi-step items are numbered, and progress stays visible. Everything the leader produces is a report addressed to you, so this skill decides what you end up reading.
|
|
|
|
A team's way of working settles into skills, and a new agent inherits it by attaching one. Import is not the only source: **New skill** offers four routes — create manually, import from a local folder, import from URL, and copy from a local runtime — not covered in detail here; see [Skills](/skills):
|
|
|
|
|
|
|
|
Read the files of a third-party skill before importing it: Multica does not sandbox them, and a skill's content is handed to the AI coding tool as-is.
|
|
|
|
## The second issue: hand it to the squad
|
|
|
|
Give the squad a complete piece of work: turn the site into a generic template — replace the real name with a placeholder photographer name and the real email with `[email protected]`, leaving layout and content structure untouched. This issue does not have to be written by hand: describe the requirement to Lead in Chat and create it with **Create with agent**, assigned to the squad. A squad, like an agent or a member, can appear anywhere an assignee can:
|
|
|
|
|
|
|
|
In the generated issue, the requirement is already organized into a structured description, and the badge next to the title shows the leader has taken it:
|
|
|
|
|
|
|
|
What follows is all the leader's work. In its delegation comment it adds two constraints the issue did not have — the placeholder identity must be consistent site-wide, and the sweep must cover metadata and the README — before handing off to Engineer. When Engineer finishes, it reports the PR on the same timeline:
|
|
|
|
|
|
|
|
The review comes back with zero findings and Lead delivers: it mentions you for sign-off, leads with the conclusion, then the PR link, a description of the changes, and two points that need your judgment, and closes by saying that nothing merges without your approval:
|
|
|
|
|
|
|
|
From organizing the requirement, to settling the approach, development, review, and the delivery report, no step of this issue needed you to connect it. Sign-off works the same as on MUL-1; you can also have it start a local server and look in the browser, which is not repeated here. Done is still yours: reply to merge, or change the status by hand.
|
|
|
|
## Automation: Autopilot
|
|
|
|
Every trigger so far started with you: assignment, mention, chat. **Autopilot** is a fourth kind of trigger, starting work automatically on a schedule.
|
|
|
|
<Steps>
|
|
<Step>
|
|
|
|
Configuring it takes one sentence: tell Multica helper that at nine every Monday morning, Reviewer should run a full check over the site's repository — redundancy and dead code, questionable structure, places that could follow conventions better — writing findings into issue comments and changing no code:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
Open the **Autopilot** page: the executor, the prompt, and the schedule (cron plus timezone) are all configured. There are two run modes:
|
|
|
|
- **Create Issue** (default): every trigger creates an issue first, so the work lands on the board with history and comments identical to any other issue;
|
|
- **Run only**: executes without creating an issue, leaving a record only in the autopilot's run history; if a run finds nothing, nothing shows up on the board.
|
|
|
|
A periodic check uses Create Issue mode. Rather than waiting until Monday, click **Run now** to trigger once immediately:
|
|
|
|
|
|
|
|
</Step>
|
|
<Step>
|
|
|
|
The issue is created and Reviewer starts checking. From then on, at the same time every Monday, the same check creates a new issue automatically, with nobody needing to trigger it:
|
|
|
|
|
|
|
|
</Step>
|
|
</Steps>
|
|
|
|
Triggers support webhooks in addition to schedules, and the executor can also point at a squad — see [Autopilots](/autopilots).
|
|
|
|
## Working with other people
|
|
|
|
So far you have been the only human member of the workspace. Under **Settings → Members**, invite others by email; they create issues, @-mention agents, and join squads the same way you do, with several people and several agents working together on the same set of issues:
|
|
|
|
|
|
|
|
## Closing
|
|
|
|
Once issues pile up, there are tools for organizing them: a **Project** groups related issues and tracks them as one unit (see [Projects](/projects)). More ways to organize are being added, and **Space** is close to ready.
|
|
|
|
Looking back at the path: starting from an empty workspace, connecting one computer, building four agents, running two issues, then handing coordination to a leader and periodic checks to Autopilot. By the end, all that is left for you is describing the requirement and signing off on the result.
|
|
|
|
Multica is still iterating quickly; more capabilities are in the [documentation](/).
|
|
|
|
## Next steps
|
|
|
|
- [Core concepts](/concepts) — meet all of Multica's core objects in three minutes.
|
|
- [Squads](/squads) — how a leader routes work, and when to use a squad instead of a single agent.
|
|
- [Skills](/skills) — import, write, and share agent methods.
|
|
- [Autopilots](/autopilots) — full configuration for the schedule and webhook trigger types.
|