task-manager

Skill: task-manager

Contract

This skill guarantees:

• Each confirmed open commitment is one canonical action record under operations/actions/<uuid>.md.
• Each future reassessment without a current commitment is one canonical attention-trigger under operations/attention-triggers/<uuid>.md.
• operations/todo.md, indexes, briefings, Daily records, project files and automation reports are never active task stores. They may only point to or derive views from the atomic records.
• The exact schemas, sections, lifecycles and field rules come from system/data-model/profiles/action.yaml, system/data-model/profiles/attention-trigger.yaml, system/templates/action.md and system/templates/attention-trigger.md.
• A source/import run reconciles matching existing records before creating anything. The system is not append-only.
• Only a real, confirmed, personally relevant open commitment becomes an Action. Inferred work, possible improvements, raw thoughts and ideas do not enter the active action set.
• A meeting discussion, opportunity, possible pilot, suggested preparation path, or hoped-for follow-up is not a confirmed commitment. Do not set ready, action_priority, due, or target unless the source or {{user_name}} explicitly commits to the work and, for dates, to that exact timing. If no date was agreed, omit timing fields instead of manufacturing urgency.
• A later date is not automatically a task. Use an Attention Trigger when the only present need is to reassess the situation later.
• A routine incoming receipt or subscription invoice is Finance collection truth, not an immediate Action. Preserve it in the proper Finance owner and add it to the month-end booking corpus. If an Operations record is needed for the month, maintain one deferred booking-batch Action whose not_before is the first of the final five calendar days; do not create or surface one Ready Action per receipt. Real payment deadlines, dunning, suspension, cashflow, legal, disputed-performance, tax, or payment-decision risks remain separate Actions.
• waiting is an Action lifecycle because the commitment already exists; it requires waiting_on and follow_up_at.
• Project and domain files own durable outcome truth. Action records own the current execution boundary, timing and done condition. No mirrored checkbox list is allowed.
• When source evidence changes both durable truth and an Action, update both owners in one bounded mutation.
• Before closing an Action, propagate the result to its durable owner. Then set the Action to completed or cancelled; do not erase material audit history merely to shorten a list.
• Every Action has an observable Done Boundary, exactly one current Next Action, evidence links and one execution mode: agent-execute, agent-prepare or human-only.
• Keep relations typed: sources and receipts belong in evidence_refs; affected people, companies, projects and domain owners belong in optional affected_owner_refs. Never use an owner record as evidence merely to satisfy the required field.
• Dates have separate meanings: due is a real deadline, target a planned finish, not_before hides deferred work until a date, and follow_up_at rechecks waiting work.
• Prioritization is a derived, time-sensitive view. Do not encode old P0/P1/P2 buckets as permanent record truth unless the current profile explicitly admits an action_priority value.
• Google Tasks is not read, reconciled or mutated by PersonalOS operations.
• Every mutation follows [[system/contracts/core/personalos-mutation-contract]] and [[system/runbooks/core/personalos-mutation]] and ends with pos-verify on the explicit changed-file set. There is no general write-skill between this owning capability and the target records.
• After a material Action or Attention Trigger state change, invoke [[skills/priority-dashboard/SKILL]] with --reason operational-state-change. This is an explicit post-mutation rebuild, not a realtime watcher and not a second lifecycle write.