HUMMBL Operations

View saved version →

---
name: decision-record
description: Draft a durable operational decision record with status, context, alternatives, rationale, consequences, and provenance. Use for proposed or approved decisions; never infer approval from discussion.
---

# Decision Record

Create a record that lets someone who was not present understand what was decided, why, and what follows.

## Confirm the record's status

Determine whether the user wants a proposal, a review draft, or documentation of an approved decision. Discussion and recommendation do not constitute approval. When status is not evidenced, label the result **Proposed**.

Check supplied or authorized sources for an overlapping decision. Preserve identifiers and links. If a new decision changes an old one, identify the superseded record and the reason; do not erase history.

## Capture the decision

Include:

- concise title and explicit status;
- date and decision owner when known;
- context and the question or constraint being resolved;
- the decision in direct, testable language;
- meaningful alternatives, including the status quo;
- rationale grounded in cited evidence and explicit tradeoffs;
- expected benefits, costs, risks, and other consequences;
- follow-up actions, review triggers, and unresolved questions;
- source references and provenance.

Omit optional fields or mark them unknown rather than fabricating detail. Minimize confidential or personal information for the intended audience.

Drafting is read-only. Do not publish the record or modify an external decision system unless the user separately authorizes the exact write after reviewing the final content.

View saved version →

---
name: operating-brief
description: Turn authorized operational sources into a concise, evidence-backed brief for status, planning, leadership review, or handoff. Use when the reader needs decisions and exceptions rather than a generic summary.
---

# Operating Brief

Create a current, decision-useful view of operations for the requested audience and horizon.

## Evidence

- Use only material supplied by the user or sources authorized for the request.
- Prefer current primary artifacts over summaries. Retain useful links, identifiers, dates, and provenance.
- Distinguish verified facts, inferences, recommendations, and unknowns.
- Surface source conflicts instead of silently resolving them.
- Exclude credentials and minimize personal, confidential, or regulated data to what the stated audience needs.

## Brief

Adapt the depth to the situation while covering:

1. **As of** — timestamp, scope, audience, and horizon.
2. **Objective** — the operational outcome being pursued.
3. **State** — meaningful health and progress.
4. **Changes** — what became newly true during the horizon.
5. **Decisions** — made, pending, and needed, with status explicit.
6. **Risks and blockers** — likely impact, evidence, and intervention required.
7. **Next actions** — action, owner, timing, and dependency when evidenced.
8. **Unknowns** — gaps that could materially alter the plan.

Lead with decisions and exceptions. Compress routine healthy activity. Use exact dates when relative timing could be ambiguous, and do not invent owners, approvals, deadlines, or completion.

The brief is a read-only deliverable. Do not update source systems, message stakeholders, assign work, or publish the result unless the user separately authorizes the exact action.

View saved version →

---
name: work-triage
description: Convert an authorized backlog or intake set into a defensible priority queue with blockers, dependencies, and next actions. Use for backlog review, intake sorting, or focus decisions; do not silently modify task systems.
---

# Work Triage

Produce a focused execution queue from the work evidence in scope.

## Normalize the evidence

Capture only attributes supported by the source: identifier, intended outcome, status, owner, priority, due date, dependencies, blockers, and source. Mark consequential gaps as unknown. Flag duplicates, stale entries, and conflicting records for review rather than altering them.

## Make priority legible

Use the factors that materially distinguish the work:

- user, mission, or business impact;
- deadlines and external commitments;
- risk reduction and reversibility;
- dependency leverage or unblock value;
- readiness and confidence in the next action;
- effort and opportunity cost.

Avoid pseudo-precise scores unless the user already has a scoring model. State the decisive rationale behind each important placement.

Organize the result as:

- **Now** — a deliberately small set of immediately executable work;
- **Next** — ready or nearly ready after current dependencies;
- **Later** — valid work without present urgency or leverage;
- **Resolve** — duplicate, stale, underspecified, or closure-candidate work.

List blocked work separately from active work. For each Now and Next item, give its outcome, owner if known, timing, dependencies, blockers, and one-sentence priority rationale. End with decisions needed, unowned work, and the smallest useful next actions.

This triage is a proposal. Do not create, edit, close, assign, or notify through an external system unless the user explicitly approves the final mutation set. Re-read targets before any later write and stop on conflicting changes.