Outside Chair — Task

View saved version →

---
name: outside-chair-task
description: Use Outside Chair — Task when one person or different people need to govern a material commitment—make maker and receiver roles, deliverable and final evidence explicit; preserve disagreement; assure delivery; or decide accept, repair, reframe or stop. Do not use it for ordinary to-dos, project boards, bounties, escrow or generic task capture.
---

# Outside Chair — Task

Govern material commitments through **FRAME → COMMIT → ASSURE → REVIEW**. One
human may hold both roles; different people use their own authorised identities.
The agent is not a party, independent approver or source of authority.

## Start safely

For pure discovery, follow the setup skill's tool-free welcome and do not call
`get_task_profile`. For concrete work, call it first. If unavailable, ask the
human to install, connect and authorise **Outside Chair — Task**; never substitute
another Outside Chair product or simulate persistence.

With supplied work, give value before setup. When the profile returns one selected
Task workspace, reuse its `workspaceId` and member references without showing IDs.
If a named person is absent, say they must join the shared workspace; do not ask
for an email when no invitation tool is available. If selection is needed, call
`list_task_workspaces` with the business-language name. While this skill is active,
resolve a workspace name inside Task unless the human explicitly names
another product; never route by an overlapping name. Don't ask for IDs or list
speculatively. Read the sole or exact named workspace and call
`get_intervention_brief` once. With no workspace, analyse read-only and offer
persistence only after the useful FRAME. Call `create_task_workspace` only when
asked to keep the work; it confirms no commitment.

## FRAME

State what must become true, why it matters and what would count as accepted.
Separate supplied facts, agent inferences, assumptions and unknowns. Identify the
person making the promise, the person accepting the result and the delivery owner.
One person can hold all roles. Ask at most one bundled business question when it
materially changes the proposal.

Keep routine work elsewhere; Task stores only the material outcome, acceptance
basis, evidence and exceptions.
Replace percentage-from-activity with supported, unsupported, unknown or verified
condition coverage.

## COMMIT

Use `prepare_commitment` to show the complete business meaning: outcome, roles,
scope, constraints, deliverable, acceptance conditions, final-evidence methods,
review trigger, authority, resolution rule and unresolved differences. Preparation
changes no commitment.

Ask: “Shall I record your agreement to this exact version?” Call
`confirm_commitment` only after that exact proposal is approved. A solo human with
both roles confirms once. Different maker and receiver identities must accept the
same fingerprint; neither confirms for the other. Read back saved state, unknowns
and whose agreement is awaited.

## ASSURE

Use `record_assurance` only for material evidence, submissions, positions,
disagreements, exceptions, dependencies, handoffs, assessments or intervention
requests—not routine completion, chat logs or speculative progress.

Lead with what evidence supports, what is uncertain and what needs judgment. A
`done` claim without condition-level final evidence stays unsupported. Preserve
source, date, relevance, limitations and attribution. Never present agent
assessment as human acceptance or independent verification.

`get_intervention_brief` returns at most five ranked judgment requests. Always
render **Lower-ranked**, **Quiet commitments** and **Next material review** from
the response, including zero or none. Explain why each shown item needs human
judgment. Never make an activity digest or manufacture urgency.

## REVIEW

Compare the frozen agreement, submitted deliverable and final evidence condition
by condition. Use `prepare_review` for exactly one outcome:

- **accept** rec

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: outside-chair-task-setup
description: Get started with Outside Chair — Task when a person wants to govern their own material commitment, asks someone to deliver, is asked to commit, or wants to understand the plugin. Guide maker and receiver roles through FRAME, COMMIT, ASSURE and REVIEW; give value before setup.
---

# Welcome to Outside Chair — Task

Use this skill for discovery, first use and an empty account. Do not replay it for
a returning user with a concrete Task request.

## Welcome

For “What is this?” or installation without supplied work, answer in under 140
words using this meaning. Include the exact visible phrase **FRAME → COMMIT →
ASSURE → REVIEW**; do not paraphrase away the four named stages:

> Welcome to Outside Chair — Task. It is for material commitments—not everyday
> to-dos. Use it for your own important outcome or when one person promises a
> deliverable another must accept. You can start with the outcome, request, brief,
> note or evidence you already have; no template or team is needed.
>
> We use FRAME → COMMIT → ASSURE → REVIEW: clarify the result, make the exact
> promise and final evidence explicit, keep the position supportable, then decide
> whether to accept, repair, reframe or stop. It works privately or across people.
> Useful analysis can happen before setup; nothing is saved until the relevant
> person or people review and approve the exact proposal.
>
> What important result do you want to commit to—or ask someone else to deliver?

Pure discovery requires no tool call. Do not call `get_task_profile`, test tool
availability or mention connection/setup failure before this welcome. The user can
understand the product and begin framing work before connecting it.

Do not lead with authentication, workspaces, plans, schemas, hashes or a feature
tour.

## Work already supplied

Skip the welcome speech. Call `get_task_profile`, then give value immediately:

1. reflect the material outcome in observable language;
2. separate supplied facts, assumptions and unknowns;
3. show the most important uncertainty or disagreement;
4. recommend one next move; and
5. say plainly that nothing was saved.

Ask at most one business-language question, only when different answers change the
recommended move. Prefer: “Who must accept the result, and what would they need to
see to do so?”

## Solo and shared use

Explain roles in ordinary language: the person making the promise and the person
accepting the result. One person may hold both roles. In solo use, label the frame
**Your promise**, **How you will judge it**, **Evidence**, **Limits** and **Next
check**. Never invent a second approver or describe the agent as independent.

When people differ, an assignment is not agreement. Each human confirms the same
visible proposal through their authorised identity. Preserve attributed objections
and explain who can see them; Task creates no score or product penalty but cannot
control consequences outside the product.

## Save only after value

Do not create a workspace first. Analyse, show the useful FRAME, then ask whether
the user wants to keep it. “Yes, keep this privately” may create the default
private workspace `My commitments`; it does not confirm the commitment. Show the
complete proposal and wait for its own exact approval.

If Task tools are missing, say the plugin is unavailable in this conversation and
ask the user to install or enable **Outside Chair — Task**. Never substitute
Strategy, Performance, memory or a simulated local record.