cast-org

The organization is read from the top down: initiatives, the goals the company set; the projects that carry each; the plans and tasks inside a project; the roles that lead projects and own initiatives; the people they report to; and the sessions that do the work. This skill is the conversation about it, held where the person already is. The org page holds the same conversation beside the chart. A change is approved on a card here or on that page, and nothing moves until they approve it.

Look first

Every org verb reads the active workspace unless --team names another; --team personal is the person's own. Say which workspace you are looking at in your first line: the wrong company is the commonest wrong answer here, and a list of roles does not reveal it.

cast org ls                      # people, roles with their scopes, the sessions under each
cast org proposals               # anything already waiting on a person
cast org health                  # load, flags, stale records, span
cast initiative ls               # the goals: status, owner, health, target
cast org inputs                  # ends with coverage: projects with a lead, work outside any project

Then:

cast org init --here             # no roles yet: the briefing, in this session
cast org review --here           # roles exist: the same briefing in review mode

Follow the briefing it prints. It carries what to read, the grounding rules, the initiative and coverage rules, the capacity model, the standing versus program rule, the honesty rules, the spec, and how the conversation is held; do not restate or replace them.

When one person works in one area with nothing filed, there is nothing to organize: say so, say what would make a chart worth having, and stop.

The conversation

Read everything first, then talk. Lead with the reporting structure: who reports to whom, what each role looks after, and where the person's own sessions go, as it stands and as you would change it. Short messages in plain words, one thing at a time. Ask what the records cannot settle, take the answer, and move on. Hold the evidence and give it when asked; no ids in prose, nothing about yourself.

When something is agreed, or the records settle it on their own, post it as a small proposal:

cast org propose --spec proposal.json [--supersedes op-N]

Put its short id on its own line, where it renders as a card. The card says each change in a plain sentence, with what was there before and the reason you gave. The command also prints each change's number. When the conversation turns to one change, write the short id, # and that number on its own line, and it renders as the card for the one role, goal or record it changes.

The person answers the card: they approve a change, reject it or write back on it, and their answers reach you together, as one message that names each change. What they approved is already applied when you read it. Their words on a rejection or a note are their edit: revise the proposal from them and say what changed in a sentence.

Many small proposals over the conversation, never one document. An edit the person gives in plain words folds into the next proposal, or into one you posted, in place:

cast org revise op-N --remove 3 --note "growth is not dead yet"
cast org revise op-N --amend 1 --edits '{"scope":{"add":["pr-12"]}}' --rationale "why"
cast org revise op-N --add change.json          # one spec change, or a list

A change they already decided is refused by name, a rejected one included: what replaces it goes in with --add. A change they wrote back on still waits, and takes --amend. A proposal somebody else posted is theirs: an edit on it lands on the page by change number, and a withdraw is theirs, on the page or with cast org proposals --withdraw op-N at their own shell.

Proposals already open outrank a new one on the same subject. Read them back in a few plain lines, compare with what health says now, and name a difference only where it would move a change. Do not post their changes again and do not withdraw them.

End

A change no proposal carries, a role retired, created or moved by hand, is made on the org page and nowhere else; a shell is refused, so point them at the page, not at a command. The hire and every approval are theirs: no session decides a staffing change. A head of people, once hired (cast org staff, or the button on the page), holds this conversation weekly without them.