Przejdź do treści
Biblioteka skilli
Produktywność osobista · Integracja z narzędziem

setup

/setup

Konfiguruje Agorę, wspólny notatnik rodziny lub firmy na Google Drive i Kalendarzu, także dołączanie kolejnych osób.

Repozytorium
cruna-plugins ↗
Licencja
Apache-2.0
Ostatnia zmiana repozytorium
11.11.2026

Ocena i bezpieczeństwo

100/ 100Klasa: dobry
Format25 / 25
Frontmatter z nazwą i opisem, poprawna nazwa, opis do 1024 znaków, nazwa zgodna z folderem.
Odkrywalność25 / 25
Opis mówi, kiedy użyć skilla, ma sensowną długość i jest w 3. osobie.
Treść35 / 35
Co najmniej 150 słów i do 500 linii, nagłówki, listy kroków, przykłady albo kod.
Higiena15 / 15
Bez zaślepek typu TODO, bez ścieżek Windows, z licencją.
Ryzykobrak sygnałów w skanie
Pliki w paczce
8
Skrypty
0
Komentarze HTML
0
Adresy URL w SKILL.md
0
Przestarzałość

Brak sygnałów. Repozytorium zmienione 11.11.2026, bez odwołań do wycofanych modeli i API.

Licencja

Apache-2.0, otwarta: można używać i zmieniać, z zachowaniem licencji i informacji o zmianach.

Co robi i kiedy

Konfiguruje Agorę, wspólny notatnik rodziny lub firmy na Google Drive i Kalendarzu, także dołączanie kolejnych osób.

Wyzwalacze z opisu

set up Agoraget startedadd my wife to Agoram joining our family AgoraI installed Agora on ChatGPT toofinish setupwe have Workspace now
Oryginalny opis (EN)

Sets up Agora, the shared family or business notebook on Google Drive and Google Calendar. Use when the user wants to start Agora for the first time ("set up Agora", "get started"), when a person joins an existing Agora or an existing member starts using it from another app ("add my wife to Agora", "I'm joining our family Agora", "I installed Agora on ChatGPT too"), when a setup was left halfway ("finish setup"), when a one-person Agora must move to its own assistant account because someone is joining, when an Agora moves to a Google Workspace shared drive ("we have Workspace now", "move Agora

Jak działa

  1. 1. Load the rules and pick the branch
  2. 2. New root
  3. 3. Join
  4. 4. Migrate (solo → dedicated account)
  5. 4b. Move to shared drive (basic → shared services)
  6. 5. Email (turn on in an existing root)
  7. 6. Offboard
  8. 7. Verify
  9. 8. Memory step
  10. Output
Sekcje z nagłówków SKILL.md, w oryginale · 200 linii, 3 390 słów
Podgląd SKILL.md
---
name: setup
description: Sets up Agora, the shared family or business notebook on Google Drive and Google Calendar. Use when the user wants to start Agora for the first time ("set up Agora", "get started"), when a person joins an existing Agora or an existing member starts using it from another app ("add my wife to Agora", "I'm joining our family Agora", "I installed Agora on ChatGPT too"), when a setup was left halfway ("finish setup"), when a one-person Agora must move to its own assistant account because someone is joining, when an Agora moves to a Google Workspace shared drive ("we have Workspace now", "move Agora to a shared drive"), when the group wants email turned on ("turn on email", "connect Gmail to Agora"), or when someone leaves ("remove Simona from Agora").
---

# Agora setup

Setup turns an empty Google Drive and Calendar into a working Agora **root**, brings each member onto it, and takes them off it when they leave. It has six branches: **New root**, **Join**, **Migrate** (always followed by Join), **Move to shared drive** (followed by Join for every other member), **Email** and **Offboard**. Pick one in step 1 and follow only that branch. Every branch ends with the same **verification**; every branch but Offboard ends with the same "what you can do now" message.

**Shared services mode** (rules → Vocabulary → Mode): wherever a step below names it, follow that step's section in [references/shared-services.md](references/shared-services.md) ("shared-services.md → 2b"), which adds to the step or replaces the parts it names. Migrate and Move to shared drive start from basic mode only.

**Checklist**: every branch records its progress in `setup.md` (rules → Setup checklist; template in rules → File kinds → templates), so a user can stop halfway and pick up later, in this app or another. Tick a box the moment the step it stands for meets its Done when, write the file by replace (rules → Replace) with a fresh Updated line, and set `state: done` only when every box is ticked. Resuming, start at the first unticked box; step 7 re-checks the ticked ones. A `setup.md` written before email existed has no Email boxes: email is off there; add the root Email box ticked "(off)" the next time you write the file.

**Github members** (rules → Vocabulary) come only from the `add-interest` handoff, when a developer links a repo from Claude Code with `cruna-pm-github`; setup's questions and messages stay on the people and interests the user names. "Every member" and "each member" below mean the people in Members: what a github member lacks is in rules → Vocabulary, and Join and step 7 pass it by. Offboard is the one branch that removes one.

## 1. Load the rules and pick the branch

Load the `rules` skill. Follow rules → Finding the root, then pick the branch:

| What you find | Branch |
|---|---|
| No root, and the user is starting fresh | **New root** |
| No root, but the user says someone already set one up | Their connectors are logged in as the wrong Google account, or, in a Workspace team, the admin hasn't added them to the shared drive yet (item 4, step 2): walk prerequisites item 3, then search again |
| A root whose `setup.md` says `state: todo`, and the user is finishing setup ("finish setup", "let's carry on") | The branch of the first unticked box that this user can do: Root boxes → **New root**, a Member section → **Join** for that member, Migration → **Migrate**, Move to shared drive → **Move to shared drive** |
| A root, and the user is joining it or using it from a new app | **Join** |
| A solo root (one member, `assistant_account` is that member's own account) and someone new is joining | **Migrate**, then **Join** for the newcomer |
| A basic mode root, and the group now has Google Workspace and wants each member on their own account ("we have Workspace now", "move Agora to a shared drive") | **Move to shared drive** |
| A root, and the user wants email turned on ("turn on email", "connect Gmail") | **Email** |
| A root whose `setup.md` has unticked Email boxes, and the user is finishing setup | **Email** for the root box, **Join** for a Member Email box |
| A root, and a member is leaving ("remove me from Agora", "Simona no longer needs access") | **Offboard** |

Identity: in a found root, follow rules → Identity and read the person's memories (rules → Memory step). In a new root, the person talking becomes the first member during the interview.

A found root with no `setup.md` was set up before the checklist existed: run step 7, write `setup.md` with a box ticked for every line that passes, then carry on with the branch.

Done when the branch is chosen, `setup.md` (if the root has one) is read, and, for a found root, you know who is talking.

The prerequisites checklist is the `rules` skill's `references/prerequisites.md`; "item N" below means its numbered sections. Walk each item with real calls and end it **ready** or **blocked**, as that file says. A blocked item stops the branch until its fix is done, except item 5 sharing for someone not present: record it and carry on.

**Persist**, through the connectors only (rules → Connectors only). Everything setup asks of the connectors is within their reach: creating folders and files, and sharing the root folder with members. A failed call is a hiccup to retry, never a reason to stop, to call an item blocked, or to hand the work to the user. Only the steps marked as clicks belong to the user.

## 2. New root

### 2a. Prerequisites

First ask: "Does your group use Google Workspace, with work accounts on your own domain?" Recommend yes for a business with its own domain, no for a family on Gmail.

- No → **basic mode**: the steps below.
- Yes → **shared services mode**: follow shared-services.md → 2a in place of the steps below.

#### Basic mode

1. Tell the user, in two plain sentences, what they will do by hand along the way: the calendar connector can't share calendars, so sharing the Agora calendar with each member (and each member's own calendar with Agora) is a few clicks in Google Calendar, which you'll guide step by step. Everything else you do yourself.
2. Ask: "Will anyone else use this with you?"
   - Yes → a dedicated **assistant account** owns everything (item 4 applies).
   - No → **solo**: the user's own account plays the assistant role; skip item 4. Tell them they can move to a dedicated account later when someone joins.
3. Walk item 1, item 2, then (dedicated only) item 4, then item 3. The assistant account must exist before the connectors log in as it.
4. For item 3, confirm whose account the connectors use: the primary calendar in the calendar list carries the account's email address. It must be the assistant account (or the user's own, when solo).

Done when items 1–4 are each ready (item 4 skipped when solo).

### 2b. Interview

Follow [references/interview.md](references/interview.md): root name, language, timezone, members, layout convention, first interests and instances. **Grill gently**: a few questions per round, each with a recommended answer the user can accept with one word.

As soon as the root round is confirmed, create the root folder in the assistant account's Drive, named after the root display name, and `setup.md` in it, with Prerequisites ticked. Write each later round to setup.md → Interview the moment the user confirms it, and add a Member section for every member who will use the root (the owner's Connectors and plugin box ticked). Resuming, read the confirmed rounds back in one line and start at the first missing round. Shared services mode: shared-services.md → 2b.

Done when the user has confirmed the summary at the end of the interview and the Interview box is ticked.

### 2c. Build

Build in this order from the answers in setup.md → Interview, writing every file from its template (rules → File kinds → templates) in the root's language, and following rules → Working with Drive. Resuming, skip what verification shows is already there.

1. Root folder: it exists since the interview.
2. `org.md`, with `agora: root` in its front-matter, every member in Members, the layout convention, and one Access row per member (Drive and calendar "pending" until step 2e).
3. `landing/`, `reviews/`, `todos/` (empty: `todo.md` comes with the first to-do), `memories/` with `shared.md` and one `<slug>.md` per member (title line only, plus anything durable the interview revealed).
4. The Interests table in `org.md`, every interest from the interview with its description and color (colors as in `add-interest` step 5), written once (rules → Replace).
5. Each interest and instance from the interview, built with step 4 of the `add-interest` skill, then the interest level of its step 6 (each interest's `index.md` and `status.md`, rolled up from its instances). You already hold the root and the answers, so skip its questions.
6. Root `index.md` and `status.md`, rebuilt once at the end of the build so they roll up everything below.
7. The **system calendar** is the assistant account's own primary calendar (rules → Calendar conventions): nothing to create or search for. List calendars and confirm the primary one carries the assistant account's email and the timezone in `org.md`. A different timezone is a click fix for the user, signed in to Google Calendar as the assistant account: **Settings** → **General** → **Time zone**.

Shared services mode: shared-services.md → 2c, for items 2 and 7.

Done when every item above exists exactly once and the calendar list shows the system calendar in the root's timezone. Then tick Build and remove the Interview section from `setup.md` (keep the email answers until step 2d has used them); tick each member's "In Members and Access" box.

### 2d. Email

Follow [references/email.md](references/email.md), New root. Declined: the root Email box is ticked "(off)" and nothing else changes. Then remove the email answers from `setup.md` → Interview.

Done when the root part's completion criterion holds (or the box says "(off)"); (email on) every member interviewed has their addresses (not solo) and Email importance line recorded, and the owner's member part is done or blocked.

### 2e. Sharing

Walk item 5 for every member:

1. **Root folder**: share it yourself through the Drive connector, as editor, with each member's email. When a call fails, read the folder's permissions, then share again, one member at a time, until the permissions list every member.
2. **System calendar**: the calendar connector can't share it, so give the click steps of item 5 to whoever is signed in as the assistant account, one member at a time, and wait for each to be done.
3. **Personal calendars**: ask each member to share theirs at the level recorded in `org.md`, with the click steps of item 5.

Update the Access table in `org.md` with what is now true, and tick each sharing box in `setup.md` as its check passes. A box waiting on someone not present stays unticked, naming who does it.

Solo roots: nothing to share; mark the owner's row as owner and tick both sharing boxes "(solo)".

Shared services mode: shared-services.md → 2e, in place of steps 1–3 and of this Done when; nothing is shared.

Done when the root folder's permissions, read with a real call, list every member with an email as editor; the Access table shows each member's real Drive and calendar access; and every sharing box is ticked or names who still has to do it.

### 2f. Routines

Give the user the three routines from [references/routines.md](references/routines.md), filled in for them, then walk item 6.

Done when the user confirms the three routines are in their scheduled list (tick their Routines box), or item 6 is recorded as blocked (the box stays unticked).

Go to step 7.

## 3. Join

For a new member, or an existing member on a new app. Run it in the joining person's own app. Shared services mode: shared-services.md → 3, in place of the steps below and their Done when.

1. Walk items 1, 2 and 3, and item 7 when `org.md` says `email: on`. The connectors log in as the assistant account in `org.md`; the person gets its password from whoever keeps it.
2. Find the root (rules → Finding the root) and follow rules → Identity. Find their Member section in `setup.md`: a new member gets one now (all boxes unticked but Connectors and plugin; an Email box when email is on); an existing member on a new app gets Connectors and plugin ticked and Routines unticked (and Email unticked, when email is on). Steps whose boxes are already ticked are done: skip them.
3. **New member only**: interview them with the Members round of [references/interview.md](references/interview.md) (just for themselves). Add them to Members and Access in `org.md`, create `memories/<slug>.md`, and walk item 5 for them as in step 2e: share the root folder yourself until its permissions list them, then guide the click steps that share the system calendar with their personal Google account and their personal calendar with the assistant account at the level they choose.
4. **Existing member, new app**: update their Access row ("Client connected").
5. **Email on**: run the member part of [references/email.md](references/email.md) for them (a new member was asked the email questions in step 3).
6. Give them their routines from [references/routines.md](references/routines.md) and walk item 6.

Done when the person is in Members and Access with their real access, the root folder's permissions list them as editor (new member), they have a memories file, item 6 is ready or blocked, (email on) their Email box is ticked or names what is waiting, and each of these is ticked in their Member section. Go to step 7.

## 4. Migrate (solo → dedicated account)

Run it with the root's owner, before the newcomer joins. Add a Migration section to `setup.md` with one box per step of [references/migration.md](references/migration.md) (`state: todo`), then follow it: create the assistant account, hand it the root folder and the Agora events, reconnect the owner's connectors, and update `org.md`. Tick each step as its Done when holds.

Done when migration's own completion criterion holds and every Migration box is ticked. Then run **Join** for the newcomer.

## 4b. Move to shared drive (basic → shared services)

Run it with the root's owner (the admin, for a team), in their own app. Add a `## Move to shared drive` section to `setup.md` with one box per step of [references/move.md](references/move.md) (`state: todo`), then follow it: it brings the root, its future events and its mail onto shared services, losing nothing. Tick each step as its Done when holds.

Done when the move's own completion criterion holds and every Move to shared drive box is ticked. Go to step 7; each other member then runs **Join** in their own app.

## 5. Email (turn on in an existing root)

Run it with any member. Follow [references/email.md](references/email.md): ask the Email questions of [references/interview.md](references/interview.md), run the root part, then the member part for each member present. Members not present do their member part when they next run setup ("finish setup") or Join.

Done when the root part's completion criterion holds, the present members' parts are done or blocked, and every other member's Email box names them. Go to step 7.

## 6. Offboard

Run it with the root's owner, signed in as the assistant account where a step needs clicks. Follow the `rules` skill's `references/prerequisites.md` → Offboarding a member, confirming each step with the owner before you do it or hand it over:

1. Remove the member's editor access on the root folder (yourself when the Drive connector can change sharing; otherwise give the owner the click steps).
2. Remove their access to the system calendar: Google Calendar (as the assistant account) → Settings → the calendar → Share with specific people → remove them.
3. Ask the member, if reachable, to disconnect the Drive and Calendar connectors (and Gmail, when email is on) in their client and delete their Agora routines.
4. When they knew the assistant account's password, have the owner change it and pass the new one to the remaining members.
5. Update `org.md` (rules → Replace): write `removed YYYY-MM-DD` in their Members Notes, and `removed` under Drive and System calendar in their Access row. When their Mail from cell holds the retired assistant address (Move to shared drive, step 7), move that address to another member's Mail from cell in the same write, asking the owner whose, so mail from it stays member mail. Their diary entries, documents and `memories/<slug>.md` stay: they are history.
6. Remove their Member section from `setup.md` and set `state` from the boxes left.

Shared services mode: shared-services.md → 6, in place of steps 1–4 and of this Done when. A member who is `calendar_owner` blocks the branch until the calendar is transferred.

**A github member** ("remove pm from Agora") takes one step in place of 1–6: remove its Members row and every Conventions row managed by it (`managed by cruna-pm-github`, its slug under Since), writing `org.md` once (rules → Replace). Its diary entries and to-dos stay. Tell the owner that the repos stay linked in GitHub until a developer unlinks them with `cruna-pm-github`: the next link adds the member back.

Done when the member has no editor access on the folder or calendar, the Members/Access rows in `org.md` show them removed, no removed member's Mail from cell holds the retired assistant address, and `setup.md` has no section for them; for a github member, when `org.md` has no Members row for it and no Conventions row managed by it. Go to step 7.

## 7. Verify

Check the root with real calls, never from memory of what you built:

- `org.md` downloads, its front-matter has `agora: root`, and every member has a Members row and an Access row (a removed member's rows say so, and the folder and calendar no longer list them).
- Root `index.md` and `status.md`, `landing/`, `reviews/`, `todos/`, `memories/shared.md` and one `memories/<slug>.md` per member exist.
- Every interest in `org.md` and in the root `index.md` has a folder with `index.md` and `status.md`; every instance has `index.md`, `status.md`, `diary/` and `documents/`.
- No file name appears twice in the same folder (rules → Replace).
- Basic mode (shared services mode: shared-services.md → 7 in place of these lines):
  - The calendar list's primary calendar carries the assistant account's email, as `calendar` in `org.md` does.
  - The connected account owns `org.md` (prerequisites item 3).
  - The root folder's permissions list every member with an email as editor (a removed member: not at all).
- When `org.md` says `email: on`: a Gmail search returns, and the mailbox is the assistant account's (prerequisites item 7); `inbox.md` exists once at the root; `memories/shared.md` has an Email importance line; every member using the root has addresses in Mail from (not solo).
- `setup.md` has a Member section for every member who uses the root, each box ticked exactly when what it stands for passes the checks above (or, for calendar sharing and routines, the person confirmed it), and `state` is `done` exactly when every box is ticked.

Fix what fails and check again. Done when every line passes; then tick Verify.

## 8. Memory step

Follow rules → Memory step. Setup usually learns a lot (roles, habits, how people want to be addressed): write it now.

Done when: anything durable you learned is in `memories/`, or you found nothing new.

## Output

A short message in the root's language, no technical terms. Offboard: one line saying who was removed, anything still pending as a to-do with who does it, and the `remember` line, if any. Every other branch:

1. One line: the Agora is ready (or: this person is now part of it), with the root name.
2. Every unticked box in `setup.md`, as a to-do with who does it ("Marta: accept the calendar invitation"), and that saying "finish setup" picks up from there. Nothing unticked: say setup is complete.
   When the interview found a sheet or note they already keep, offer to bring it in now, one question per sheet (the `file-document` skill, Import).
3. **What you can do now**, four or five lines with an example sentence each, drawn from their own interests:
   - Tell me news: "Nina's blood test came back fine." (`log`)
   - Add a file: drop it in the `landing` folder and tell me. (`file-document`)
   - Set a reminder or appointment: "Remind us to renew the car insurance on 12 March." (`schedule`)
   - Ask: "What's pending for Nina?" (`ask`)
   - Keep a to-do: "Add a to-do: renew the car insurance by Friday." (`todo`)
   - Track something new: "Start tracking the house renovation." (`add-interest`)
   - Email on: "Forward me the client's email", "Draft a reply to Mario". (`email`)
4. When reviews will arrive (each morning, Sunday evening, the 1st), and that "help" explains anything else.
5. The `remember` line, if any.
Pliki w paczce (8)
  • SKILL.md 21 KB
  • agents/openai.yaml 1 KB
  • references/email.md 3 KB
  • references/interview.md 5 KB
  • references/migration.md 4 KB
  • references/move.md 8 KB
  • references/routines.md 1 KB
  • references/shared-services.md 9 KB

Wersje

RepozytoriumWynikLicencja
Ta strona · Cruna-Noise-To-Signal/cruna-plugins100Apache-2.0
HwangSlater/harness-fit100MIT
nesquikm/dev-process-toolkit100MIT
userKael/rastro100MIT
als-apg/osprey100BSD-3-Clause
dedujeong/gemba100Apache-2.0
eigenwise/eigenwise-toolshed100MIT
awrshift/agent-memory-kit100MIT
lifecycle-innovations-limited/claude-ops100MIT

Migawka bazy z 13.11.2026 · wersja paczki 91d3f55c671b (skrót SHA-256 całej paczki)

Pobrania w ostatnich 30 dniach: 0 · ranking

Zgłoś problem z tym skillem: szkodliwa treść, błędny opis albo prośba autora o usunięcie.

Podobne skille

  • 100help
    Wyjaśnia, jak działa Agora, wspólny notatnik rodziny lub zespołu na Google Drive i Calendar, i naprawia go, gdy źle działa.
  • 100add-interest
    Dodaje nowy temat albo osobę do notatnika Agora na Dysku Google, np. klienta, remont lub zajęcia pływackie.
  • 100work-in-agora
    Przegląda tablicę zleceń Agora i wskaźniki gospodarki, a zapisy oraz płatne prace wykonuje tylko za zgodą użytkownika.
  • 100agora-webhooks
    Odbiera i weryfikuje webhooki Agora, czyli zdarzenia kanałów RTC, z podpisem Agora-Signature, na potrzeby obsługi połączeń.
  • 90agora-dispatch-gate
    Ocenia zadania przed przydzieleniem w Agora: weryfikowalność, odwracalność i budżet, dobiera poziom autonomii i układa specyfikację.
  • 100agora
    Pomaga budować w aplikacjach agentów głosowych AI, rozmowy wideo i głosowe, streaming na żywo, udostępnianie ekranu, wiadomości, nagrywanie i tokeny uwierzytelniania oraz używać CLI agora: logowanie, quickstarty, diagnostyka i serwer MCP.

Uwagi i zgłoszenia

Wiadomość trafi do Bartosza Sokolińskiego. Adres e-mail jest potrzebny tylko do odpowiedzi. Szczegóły w polityce prywatności.