Build or review a business work plan
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Use the objective, scope, beneficiaries, obligations, deadlines, roster, capacity, existing commitments, and acceptance requirements. For progress review, obtain the prior plan and supplied updates rather than assuming live status. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the intended business outcome and scope boundary. Identify who owes what to whom; a task owned by a customer is not automatically an obligation the business owes that customer. 2. Break the outcome into meaningful deliverables with inputs and acceptance evidence. Preserve requirements stated by the user and label additional acceptance criteria as proposals, not silently implied commitments. 3. Sequence deliverables by actual dependencies and decision gates. Choose granularity appropriate to coordination and uncertainty instead of fixed task durations, phase counts, or engineering workflows. 4. Assign supplied owners and dates, identify unassigned work, and reconcile workload against capacity. Include stakeholders and real deadlines when relevant; do not invent names or dates to eliminate unknown fields. 5. Plan contingencies for material uncertainty, including unavailable inputs, approval delays, scope tradeoffs, and handoff failures. Separate required approval evidence from merely convenient review and do not seek redundant permission for already-authorized planning. 6. In review mode, compare supplied progress to acceptance evidence. Distinguish done, in progress, blocked, proposed, and unknown; a summary or status claim alone may not prove the deliverable meets its criteria.
Output: Return a concise plan or roadmap with deliverable, obligation direction, owner, date, dependency, acceptance evidence, and status; add assumptions, risks, and the next decision.
Quality checks: Check traceability to requirements, feasible sequencing and capacity, explicit proposed criteria, and honest completion status. No task-system, calendar, database, or filesystem updates occur.
Worked example: A supplier owes a revised service proposal Friday; the customer owes usage volumes Wednesday. Record the volumes as a customer-owned dependency and the proposal as the supplier obligation. A suggested approval checklist remains proposed unless agreed. If volumes are late, offer a bounded-assumption proposal or date discussion rather than silently marking the supplier task complete.