How we plan and track work

How Life Itself keeps track of its work, for new team members and for AI agents opening our repositories.

Summary

• Every initiative and project has one record that holds the current truth (owner, status, where its tasks are; for initiatives, priority). By default a project's record is a Markdown file in the projects/ folder of the repository where its work lives, made with the portfolio skill and, for big or new work, planned with the project-planning skill (Rufus, 22 Oct; to confirm with Uriel). During the trial a Media House project's Asana project counts as its record.
• The planning repository is the central index. It holds the initiative records and is becoming a set of pointers to project records, each with a copy of the last status it read. The project's own record always wins.
• Tasks live in one tracker per kind of work: Asana for Media House, Beads for everything else. GitHub Issues is allowed but little used. Work that crosses teams has one owning record; the other side holds a pointer, and tasks aren't copied between tools. (On trial.)
• Uriel and Rufus write a team plan weekly or fortnightly. Plans are history, and they are where project priority is set, week to week. Initiative priority is permanent state: when it changes, it changes on the initiative's record. Thursday 12:00 to 14:00 is protected time for work on the system itself.
• Your AI builds your week from the records and trackers (Beads today; Asana is being added, so Media House uses Asana's My Tasks for now) and links every source. If the AI and the source disagree, the source wins.

Your actions: set up your computer and clone the repositories you work on (§6), then use the recipes when you need them. Unfamiliar words are explained at the end (§6).

Status as of 22 October 2026. Since the week of 19 October we are trying out one tracker per kind of work, led by Uriel, who sets the end date by 5 November; the review is due 3 December. Rows below are marked decided, on trial or open. Rufus maintains this guide, with Asdra drafting, and updates it when an open row is settled.

 HOW WE PLAN AND TRACK WORK

 ① [▤] THE RECORD (§1)
       one per initiative and per project
       owner · status · tracker
       (initiatives: priority)
       = STATE ◀ the key idea: what
         matters now is written here
          │
          ├─▷ papers: Markdown in Git (§2)
          │
          ├─▷ tasks: one tracker per kind
          │   of work, linked not copied (§2)
          │
          └─▷ planning's index points to
              each project record (§1)
                   │
                   ▼
 ② [◷] TEAM PLAN (§3)
       weekly or fortnightly
       Uriel + Rufus, Asdra deputy
       = FLOW: read it for history
       initiative priority ──▷ back to ①
          │
          ▼
 ③ [◉] YOUR WEEK (§4)
       your AI reads ① and the trackers;
       every line links its source,
       and the source wins

 ④ [⚙] THURSDAY 12–2 (§3)
       time for the system itself
       clean-up: a person confirms
       each fix ──▷ back to ① and tasks

1. The record holds the current truth

A project is bounded work with an intended outcome and an end. An initiative is an enduring area of work with no end date, such as Media House or Calls and Catalysts. Initiatives nest: Calls and Catalysts sits inside Gardens of Change, inside Seeds of Renaissance. Small tasks need no project, and articles, videos and other content items don't need one each.

Every initiative and project has one record that says what it is, who owns it, where it stands and where everything else is. By default it is a Markdown file in the projects/ folder of the repository where the work happens, next to its papers (Rufus, 22 Oct; to confirm with Uriel). An A10 Google Doc is still allowed but is no longer the default. During the trial, a Media House project's Asana project counts as its record, with a pointer from planning. Take the Global Connection Call, a new series of community calls run from the community repository. Its record, as of 22 October:

 sor-community/projects/2611-…-global-connection-call-v1.md
 ──────────────────────────────────────────────────────────
 owner:         petronella
 status:        next
 parent:        calls-and-catalysts
 done_when:     first call 29 Oct; the series
                of six runs to 3 Dec
 tracker:       beads
 status_notes:  dated lines: what changed,
                who said so

Planning is moving to keep only a pointer to each project record, with the last status it read, so the portfolio and the weekly sweep can see every project in one place. Planning's old full copy of the Global Connection Call is deprecated and being removed. The target shape:

 planning/  (the central index)
 ├── initiatives/   one record per initiative
 └── portfolio      one pointer per project:
        │           source link, owner, status,
        │           date last checked
        │
        └──▷ sor-community/projects/2611-….md
             the record itself: this one wins

The owner is the record's source: they confirm its facts. Editing a file doesn't make you its source. Status words: in-progress is active now and next is selected next (the data model lists the rest). An old date is a reason to check, not proof that work stopped.

Team plans and meeting notes are flow: a history of what we planned and decided. What matters now is state, and it lives on the records. Read a plan for history; read the record to know where things stand.

2. Where things live

Our office is a set of Git repositories in the life-itself organisation on GitHub, most of them private. Using the office picture from Post-its and filing cabinets (worth reading if the table is unclear):

Who works where: Media House (Uriel, Yo-Yo, Valerie) works in Asana; operations and planning (Rufus, Asdra, Fae) work in Beads. If you're not sure which side a piece of work belongs to, ask Uriel (Media House) or Rufus.

The rule is one home for each kind of thing. Where work crosses teams, one record owns it and the others hold a pointer; we don't copy tasks.

Where to log a new to-do:

 a new to-do
   │
   ├─ Media House?         ──▷ Asana
   │
   ├─ anything else?       ──▷ Beads: planning work in
   │                           planning's, initiative work
   │                           in the initiative's repo
   │
   └─ needs both teams?    ──▷ one team owns it;
                               the other gets one pointer

 not sure? ask Uriel (Media House) or Rufus

The trial starts from Uriel's proposal of 9 October, How Asana and GitHub work together. Asana holds public-facing and outside-collaborator work, with Uriel owning its structure; Beads holds operations, infrastructure and internal planning, with Rufus owning its structure. Changes to the other team's system go through comments, and anything going public gets a one-line notice in Google Chat. The exact line is still being agreed.

A cross-team example: a Wisdom paper release needs research work and Media House promotion. Until the written rule lands, agree which team owns it; that team's tracker holds the tasks and the other holds one pointer.

A repository or Drive folder holds working material; it isn't automatically the tracker. The record's tracker: field says which is.

On your laptop, clone the repositories you work on into one folder, so your AI can read across them:

 ~/code/life-itself/
 ├── planning/        the index, initiatives, weekly plans
 ├── podcast/         an initiative's projects and papers
 └── sor-community/   another initiative's projects and papers

3. The planning rhythm

Initiative priority is state, so it lives on the initiative records: one to four stars, set centrally by Uriel and Rufus. When it changes, the record gets a dated note naming who set it. Initiative priorities are agreed but not yet written on every record. Projects don't carry a permanent priority: which projects matter is decided week to week in the team plan.

Uriel and Rufus write a team plan weekly or fortnightly, in the Thursday slot when one is due, with Asdra as Uriel's deputy. They run the planning sweep, agree the plan, and hand the work out with an owner, a next action and a priority for each piece. The plan is saved to weeks/ (see 12 October): focus areas, owners, outcomes and the main epic for each, never a copy of the task list. The planning skill has the steps. The format is on trial.

   records (state) ──▷ sweep ──▷ team plan (flow)
        ▲                            │
        │                            ├──▷ work handed out
        │                            │    in the trackers
        └── initiative priority ◀────┘

Every Thursday, 12:00 to 14:00, is protected time for work on the system itself, such as cleaning task data or writing a skill. Changes to how we work are briefed there. Messy systems already cost us hours, so if time is short a deliverable can slip to protect the slot. Rufus owns it; the invite goes to Rufus, Uriel, Asdra, Fae and Amanda, and others join when asked.

New requests for the team, including Sylvie's, go to Uriel, who fits them into the week's priorities.

4. Recipes

Start a project

No approval or Tao issue is needed.

1. Check the portfolio: the work may already have a project or belong to one.
2. Ask your AI to use the portfolio skill to write the record in the projects/ folder of the repository where the work will live (outcome, owner, status, done when, tracker, open questions) and to add a pointer in planning's portfolio, so the sweep can find it.
3. For big or new work, then use the project-planning skill: situation, complication, question and an issue tree. It is on trial; ask Rufus.
4. Share the record with the people whose time or shared resources it needs.
5. Create the first task or epic in the right tracker, give it an owner, and link it from the record.

Update a record or decision

1. Change the facts that changed in the project's own record: owner, status, links, tracker (and priority, on an initiative).
2. Add a dated line to status_notes saying what changed and how you know.
3. Record a decision in the project's issue tree, as the question with a ✅ Answer., who decided and the date. Keep answered questions in place.
4. To pause or close work, change status and add a dated note with the reason. Keep the record.

If the project has a pointer in planning, ask your AI to update its cached status too; refreshing it automatically is planned. Edit your own project's record in its repository. In planning itself, Rufus, Fae and Asdra edit directly; anyone else can, when comfortable, or can send Rufus the link, the change and its source.

Log a task

1. Find the right tracker with the diagram above.
2. Ask your AI to check for an existing task before creating one.
3. Give it an owner, a next action and a priority. The scales line up as Beads P0 to P2 = Asana high, P3 = medium, P4 = low. Owners matter most on epics and larger pieces; small sub-tasks don't each need one. Add a due date only when the date is genuinely fixed.
4. Link it to its project.

Ask the AI what's yours this week

1. Open Claude in the planning repository, with your other repositories cloned alongside.
2. Paste: "Use the planning skill. Run the sweep for me (my ID is ) and show what's mine this week: in progress first, then ready, each with its priority and a link to its source." Your ID is your file name in people, usually your first name in lower case.
3. Open one or two of the links and check them. If the AI and the source disagree, the source wins: tell the AI and fix the record.
4. The sweep doesn't read Asana or Google Docs yet. If you're in Media House, your week is in Asana (My Tasks) until it does.

Clean up

1. Ask: "Run the planning sweep and list the exceptions: stale, unowned, duplicated, finished but still open."
2. The AI proposes fixes; a person confirms each one.
3. Close finished work with a reason, merge duplicates, add owners, fix links on records.

Asdra will run this regularly outside Asana as a data-steward routine. The weekly view is only as good as the tasks behind it.

5. For AI agents

• This guide is current. Where docs/workflow.md, the README, the data model or older pages disagree with it, follow this guide. In particular, a project record is by default a Markdown file made with the portfolio skill, followed by the project-planning skill when needed; an A10 Google Doc is allowed but not the default, and during the trial a Media House project's Asana project counts as its record.
• A project's own record, in its repository, is the source. Planning's pointer holds a cached status that may be stale: read the record itself before relying on it, and refresh the pointer when they differ.
• The record schema is the data model. Use the portfolio skill for records; never edit portfolio/index.js.
• Check for an existing record or task before creating one. Don't write to trackers or records without the person's confirmation.
• On an open row, follow the current practice stated in the table, say that it is open, and ask before deciding anything new.
• Cite the source (record path, task ID, Asana link) for every claim about tasks, owners or dates. Never fill a gap with a guess: an AI once gave a due date that did not exist in Asana.
• Never copy tasks into the other team's tool; add one pointer (the weekly requests list in Asana holds pointers, not copies). Never write task lists into Markdown. Beads tasks follow the Beads conventions.
• Most repositories are private: check sharing before sending or publishing a link.

6. Tools, who to ask, more detail

Claude (the desktop app's Code tab) is the main way in: you ask, and it reads and updates records and tasks. Set up your computer with the one prompt in Tao onboarding, which installs git, GitHub access and Beads. You rarely use Beads directly; the Beads guide explains how your AI does. Then read AI is the interface.

Ask Uriel about Media House, Asana, requests and the team plan; Rufus about records, Beads and shared skills; Asdra about clean-up; Fae about the planning site for collaborators who don't use these tools. Everyone's ID for owner: fields is in people.

Words used here:

• Record: the one document for an initiative or project that says what it is, who owns it and where it stands.
• Pointer: a short entry that points to a record or task kept somewhere else, instead of a copy.
• Tracker: where tasks live, such as Beads or Asana. Beads is a task list your AI reads and writes for you.
• Epic: a larger task that groups smaller ones.
• Sweep: your AI reading across the records and trackers to list what is in progress, ready, stale or unowned.
• Skill: a written set of instructions your AI follows for a job, such as the planning skill.
• A10: an older Google Doc template for project plans, still allowed but no longer the default.

More detail:

• Open questions, owners and dates in the project record.
• How we plan and track work (briefing, 22 Oct) and the full analysis.
• Data model, Beads conventions, planning skill, procedures.