/structure

name: structure
description: Use when the user brings any fuzzy, half-formed, or interrupt-driven input — an order from a boss, a forwarded email thread, a ticket, a chat message, a "can you look into X", a raw idea — and it needs framing before work starts. Turns the input into a structured brief (Context · Desired outcome · Goal · Owner · Next step · Decision needed). This is the AIOS's front door; run most things through it first. Trigger on "/structure", "frame this", "what's the actual ask here", "structure this", or any vague task that lacks a defined outcome.

Structuring Engine

A common leverage point: inputs arrive **without structured context, defined outcomes, or clear goals.** This skill fixes that before any work begins. Frame first, then act (or delegate).

When to run

• A new task lands fuzzy ("the boss wants the draft checked", "look into the X thing").
• A long email/chat thread needs to become an action.
• The user is about to do something the old way → apply the **Default Shift** ("to what extent could AI be leveraged here?").

The output (always this shape)

## <short title>
**Context** — what's going on, in 2-4 plain sentences. The why behind the ask.
**Desired outcome** — the end state. What does "done" look like, concretely?
**Goal** — the measurable/observable target (a date, a number, a deliverable). One line.
**Owner** — who should own this (route to the team; don't pool on the user by default).
**Next step** — the single next physical action, and by when.
**Decision needed** — the specific call the user must make, framed as a fast choice.

When a decision is involved, present it as a **fast checklist** they can answer in seconds:

- Send to the client now (yes/no)?
- Loop in <reviewer> first (yes/no)?
- Target date: <propose one>

Process

1. **Read everything given.** If it references a ticket, doc, or thread and a connection exists, pull it rather than guessing. 2. **Strip to the real ask.** Separate noise from the actual decision/outcome. Name what's missing. 3. **Fill the template.** Be concrete. If a field is genuinely unknown, write `❓ <the open question> → <who can answer>` instead of inventing. 4. **Route the owner.** Default to delegating to the right teammate; only put the user as owner when it's truly theirs (a decision, an external sign-off). 5. **Offer the next move.** After the brief, offer to: create the artifact (ticket / note / plan — allowed without approval), draft the reply in the user's voice (internal may send to team; never external without approval), and/or log a decision to `decisions/log.md`.

Guardrails (from CLAUDE.md)

• No confidential figures or sensitive/regulated data persisted to the repo. Pull live, don't store.
• **Cite, don't invent** — any regulatory/financial/legal claim cites a source or is flagged as a gap.
• **Draft, never send external.** Internal to the team may be OK; external needs approval.
• Match `references/voice.md`.