# Tududi

> Create and update high-level tasks in a Tududi installation. Use for project roll-ups, independently deliverable outcomes, task synchronization, and relevant tag management; use anarlog-updates for meeting transcript imports.

- Skill: `maratraevskiy/tududi` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add maratraevskiy/tududi`
- Raw SKILL.md: https://api.skillmd.com/api/skills/maratraevskiy/tududi/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: maratraevskiy (https://skillmd.com/u/maratraevskiy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/maratraevskiy/tududi

---


# Tududi high-level tasks

Tududi holds high-level work: a bound **Project Roll-up** summarizes a project's
state, while an **Outcome Task** represents an independently deliverable result.
Local implementation steps remain in the project's own task system.

## Establish the binding

Read `.agents/tududi.json` when it exists. Its non-secret `task_uid` identifies
the Project Roll-up; `project_uid` optionally records its Tududi project, and
`mcp_server` identifies the configured Tududi connection.

Read [the setup reference](references/setup.md) when the binding is absent or
incomplete, uses the legacy version 1 schema, or the MCP connection is
unavailable. Require Tududi's task, project, search, and tag-capable task tools;
the connected server's discovered schemas are the runtime contract.

**Complete when:** an existing binding or one unambiguous match is selected, or
the single ownership choice required to create or disambiguate it is reported.

## Choose the high-level task

For a bare `$tududi` invocation, synchronize the bound Project Roll-up. An
explicit request may create or update an Outcome Task without a repository
binding. Search by binding, source links, project, and outcome terms; read every
plausible match before deciding to update or create. Preserve human-authored
context and established assignment.

Read the target task and available project evidence before changing it. Ask
only when multiple plausible matches or destinations remain. A request to
create or update a task authorizes the necessary task reads and writes within
the established instance; it does not need a separate confirmation per MCP
tool call.

**Complete when:** one target task is matched or the one unresolved ownership
choice is reported.

## Write the task

Keep title, project assignment, and status unchanged unless the user requests
their change. A bare invocation may update the Project Roll-up's summary, next
action, and tags even when local work appears complete. Prefer the Git remote
as repository identity, falling back to the opened workspace path.

Use a concise Outcome Task description or, for a Project Roll-up, replace its
compact snapshot and append one dated history entry only for meaningful change:

```text
Repository: <remote or workspace path>
Kanban: <active task/status, or brief aggregate>
Current focus: <outcome>
Next action: <one concrete action>
Updated: <YYYY-MM-DD>

History:
- <YYYY-MM-DD>: <meaningful delta>; <source path or task link>
```

Keep history concise and append-only. Link source records instead of copying
their contents. Do not impose a full implementation specification on a
high-level task.

Read [the tag reference](references/tags.md), choose up to three relevant tag
additions, and include their assignment in the authorized task operation.
Preserve every existing tag.

**Complete when:** the task expresses the high-level outcome or current project
snapshot, with useful source links and relevant tags.

## Publish and verify

An explicit `$tududi` invocation authorizes synchronizing its known bound task.
An explicit Outcome Task request authorizes its unambiguous creation or update,
including creation and assignment of relevant tags. If no Project Roll-up
match exists during first-time binding, propose the roll-up and destination for
one confirmation. Never create among ambiguous matches.

Read [the MCP reference](references/mcp.md) before the first operation on a
connection. Verify access through the configured Tududi MCP server, write the
authorized delta, then re-read each changed task and confirm its UID, project,
status, description, source links, and tags.

If one operation fails, retain successful independent changes and report the
exact partial result. After an uncertain response, read current state before
retrying so tasks and tags are not duplicated. Do not silently replace a
missing bound task or create/revoke API keys.

Report the target task, source records consulted, changed fields and tags, and
anything left incomplete. Distinguish questions required by this workflow from
permission prompts enforced by the runtime.