agent-work

Registers and deduplicates agent-produced Works as versioned cards across GitHub, Linear, files, and tasks.

Updated Jan 27, 2026
One-click install
npx skills add https://github.com/SmallAi-API/smaihub --skill agent-work-smallai-api
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: agent-work
Source: https://github.com/SmallAi-API/smaihub/tree/main/.agents/skills/agent-work
Command: npx skills add https://github.com/SmallAi-API/smaihub --skill agent-work-smallai-api

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Agent operations produce artifacts like GitHub PRs, Linear issues, and sandbox files that are hard to track across runs. This Skill documents the Work registry that records each artifact once, deduplicates retries, and renders versioned cards under the assistant message that produced them. ## Core Features & Use Cases - Work registration and deduplication: One row per resource keyed by (resourceType, resourceId), with versions guarded by a unique (workId, toolCallId) constraint so retried registrations are no-ops. - Four write paths: Execution-time skill tool normalizers (github, linear), completion-time shell CLI scans (gh via codex/claude-code), file Work scans, and task/document registration. - Type registry with read-path gating: WORK_TYPE_ADAPTERS enforces adapter coverage at compile time, and OPT_IN_WORK_TYPES hides new card types from older clients that would crash on unknown descriptors. - Use Case: A coding agent runs gh pr create through a heterogeneous CLI; the completion-time shell scan parses the persisted command and stdout, registers the PR as a Work, and stamps the anchor so a card appears under the run's final message. ## Quick Start Ask the assistant to explain how a new shell CLI scanner or skill provider should be added to the Work registration pipeline.

Frequently Asked Questions about agent-work

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I add a new shell CLI scanner for Work registration?

Add a normalizer in packages/database reusing parseShellCommandSegments plus a WorkModel.registerShell facade method, then create a scanner file with matches, name, and register in shellWorkScanners and append it to SHELL_WORK_SCANNERS. The engine needs no changes.

How does Work deduplication work across retried registrations?

Each Work is keyed by (resourceType, resourceId) within the user scope, and each version is guarded by a unique (workId, toolCallId) constraint. A retried registration with the same real tool call id is a no-op, making registration retry-safe end to end.

Why are only successful create and edit results registered as Works?

Read-only queries, comments, merges, and branch operations are excluded so commands like gh pr view that merely print an entity URL do not register. Only successful create/edit outcomes become Works, keeping cards limited to artifacts the agent actually produced or modified.

Does the shell Work scan run when an operation ends in an error?

No. Error-terminated runs skip the completion scan via the same success gate used for file Works, so a gh create that succeeds before a later terminal failure registers no Work that round. This is an accepted trade-off with bounded cost.

Why must new Work types ship behind an opt-in gate?

Released Electron clients lag by weeks and crash on unknown type descriptors when calling descriptor.getIcon on undefined. OPT_IN_WORK_TYPES ensures requests without the opt-in receive exactly the pre-existing type set, so new card kinds never reach legacy clients.