Skills, responsibilities, and schedules

Doozy separates reusable know-how from ongoing ownership and execution timing:

• A skill (aka playbook, procedure, or prompt template) teaches a Doozy how to perform a kind of work.
• A responsibility (aka standing ownership or recurring duty) defines an outcome the Doozy owns over time.
• A schedule (aka routine, recurring task, or timed automation) decides when a responsibility or to-do runs.

This separation keeps automation understandable. The Doozy knows what it owns, how to do it, and when to act.

Save a skill

Create a skill after the work has succeeded at least once. A useful skill contains the procedure, quality bar, examples, edge cases, and reference files needed to repeat the result.

Open a Doozy, go to Skills, and choose Add skill. Give it a specific name such as Prepare weekly account-risk brief rather than Customer success.

Include:

• when the skill should be used;
• the required sources and tools;
• the steps or decision framework;
• expected output and validation;
• actions that require approval;
• examples of good and unacceptable results.

The Doozy loads a skill when it’s relevant rather than carrying every procedure in every conversation. Skills can include attached files such as templates, rubrics, sample reports, or policies.

Improve a skill through feedback

When a result misses the mark, correct the work and explain the reusable lesson. Ask the Doozy to update the skill only when the correction should apply to future to-dos of the same type.

Review the updated text before relying on it. A one-off exception shouldn’t silently become a universal rule.

Add a responsibility

A responsibility is a recurring area of ownership, such as Keep enterprise renewal risks current or Maintain release readiness.

Responsibilities appear in the Doozy’s profile and connect to the workspace to-do system. They should describe an observable outcome, not vague diligence.

Good responsibilities state:

• what remains true when the work is healthy;
• which systems define the source of truth;
• how often the state should be checked;
• what the Doozy may change independently;
• when and how to escalate.

Create a schedule

Open the responsibility or to-do and add a schedule. Choose the workspace timezone, recurrence, working-hours behavior, and what should happen when an earlier run is still active.

Before enabling a recurring schedule, run the to-do once manually with the same permissions and data. Confirm that the result is useful, the sources are available, and approvals appear where expected.

Examples include:

• every weekday at 8:00 AM;
• each Friday before the leadership meeting;
• the first business day of the month;
• after a connected event, such as a new high-priority ticket or signed contract.

Trigger work from an event

Event-triggered schedules respond to changes in connected systems. Define the event narrowly and include deduplication rules so retries don’t create duplicate to-dos or external actions.

For example:

When a new enterprise support issue is marked urgent, create an investigation to-do, collect account and incident context, notify the support lead inside Doozy, and draft any customer message for approval.

Event data can be incomplete or misleading. Require the Doozy to verify consequential facts before acting outside the workspace.

Test before enabling

A test run performs real work. It may read connected data, create workspace to-dos, write files, or request approvals. Use test accounts or limited scopes when evaluating a new schedule.

Review:

• which records were selected;
• whether the schedule uses the intended timezone;
• what happens when no result is found;
• duplicate and retry behavior;
• evidence included with recommendations;
• approval boundaries;
• where outputs and failures appear.

Manage schedules

From the workspace To-dos view, inspect the next run, recent runs, owner, status, and errors. Pause a schedule before changing its credentials, source systems, or business rules. Resume it after a manual test.

Deleting a schedule stops future runs but doesn’t undo completed actions, delete generated files, or remove the responsibility itself.

Design automation for trust

• Automate proven work, not an unclear intention.
• Keep one accountable Doozy for each schedule.
• Make no-result runs quiet and exceptions visible.
• Include evidence and links in every consequential recommendation.
• Gate sending, publishing, deletion, purchases, and permission changes.
• Make retries idempotent where the connected service supports it.
• Review schedules periodically as tools, policies, and teams change.

Frequently Asked Questions