Workspace Things

Use

ae-cli things

to manage things in the currently and explicitly specified TE space. Read the CLI reference first; do not guess IDs or automatically select another space.

When to Create Things

Use your own judgment to decide whether to create a thing; do not wait for an explicit instruction such as “create a thing for me.” Treat personal and shared spaces equally.

If any of the following signals appears, create a thing directly without asking first:

A work assignment that identifies “who does what,” such as “Have A organize X and B organize Y.”
A deliverable to be produced together with an intent to proceed, such as “produce a final proposal,” “proceed at this cadence,” or “arrange it.”
A commitment, to-do, next step, milestone, or multi-stage plan.
The user restates something that has already been decided and points toward subsequent execution.

Do not create a thing in the following situations:

Pure informational Q&A, concept explanations, or small talk.
Options are still being compared, the discussion is hypothetical, or the user explicitly says “do not decide yet.”
The duplicate check finds an existing synonymous thing—point out that it already exists and do not create a duplicate.
The user has said not to create one.

When uncertain, list the proposed things (titles, assignees, key description points) in your reply and ask the user to confirm them all at once. Do not simply format the assignments as a list and call it done.

Action Order When Creating

Confirm that an explicit AgentSpace is bound. If none is bound, do not create a thing.
Use
```
members
```
to retrieve the member list and map names mentioned in the conversation to member IDs. If there is exactly one match, use it directly as
```
--assignee-id
```
. If there are zero or multiple matches, leave the assignee empty (the server defaults to the current user) and explicitly identify the people whose assignment needs confirmation.
Use
```
list --query
```
or
```
options --query
```
to check for duplicates.
Create things one by one: the title should describe the deliverable rather than repeat the original wording, the description should state the goal and acceptance criteria, and
```
--command-id
```
should be used to ensure idempotent retries.
When needed, use
```
conversation bind
```
to bind the primary thing, or use
```
link-conversation
```
to create a regular reference.
In the reply, report the IDs, titles, and assignees of the created things, as well as which assignees still need confirmation.

Granularity: Create things in units that can be independently delivered and independently owned. There are no subtasks or groups, so do not attempt to create a hierarchy. For example, “A, B, and C each organize one section and then combine them into an overall proposal” corresponds to 4 things, not 1, and not one for every sentence.

Authorization Boundaries

Autonomous actions: create new things; add the first record to a thing you have just created.

For things the user has authorized you to advance or complete: directly append or update the corresponding progress, automatically link any delivery attachments involved in this round, and complete publication and read-back as described in the next section. Personal and shared spaces are treated the same; publication still requires

--confirm-share

. Delivering an authorized thing includes sharing those delivery files with the space to which the thing belongs.

Other rewrites to existing things, assignee changes, archiving or restoration, unbinding, and permanent deletion still require explicit authorization; a historical binding is not itself authorization. Do not automatically send messages or create scheduled tasks.

Delivery Attachment Closed Loop

When appending or updating progress, verify each file actually delivered in this round:

Use
```
asset available
```
to query this space’s files and read through every page. Link registered files by assetId and unregistered files using the returned relative path.
Publish files not yet in the space with
```
asset publish
```
: for artifacts produced in this round that have not been registered, use
```
--conversation-id --run-id --source-path
```
; for existing artifacts, use
```
--artifact-id
```
or
```
--file-token
```
. Save a separate commandId for each file and reuse it unchanged for retries.
```
linked:false
```
means the file has been published but not linked. Use only the returned assetId to add
```
asset link
```
; do not copy it again. Publish only files delivered in this round, not temporary files or the entire conversation directory.
Use
```
asset list --id
```
to read back and verify that every attachment exists and has availability=available, then read back the progress entry. Report “progress and attachments have been updated” only when both succeed; for failures, clearly distinguish between published, linked, and pending recovery.

Use the file-linking interfaces above for attachments. A local path text link cannot substitute for an attachment, and merely copying a file does not mean delivery is complete. See the CLI reference for the full parameters.

Current Conversation Binding and Execution Snapshot

Use the binding declaration frozen for the current run to determine the default thing for that run. Before executing, reviewing, summarizing, or updating the current thing, read the execution snapshot for this run using

readCommand

from the declaration; ordinary chat does not require a read.

Switching or unbinding during a run changes the conversation association immediately, but the current run—including waiting, recovery, and retries—continues to use the original snapshot. If there was no thing initially, the current run continues to have no default thing, and only the next new Run uses the latest binding. When the user explicitly specifies another thing, still read and operate on it according to permissions; do not mistake the conversation’s latest association for the current run’s snapshot.

When the user explicitly asks to bind the current conversation to a thing, uniquely locate the target, run

conversation bind

, and then read it back with

conversation primary

to confirm. If a same-name thing cannot be uniquely identified, ask the user. On success, state, “Bound; the thing context takes effect from the next turn.” Unbinding must also be confirmed by read-back. Do not treat a regular

link-conversation

reference as a substitute for successful primary-thing binding; report interface failures truthfully and do not bypass permissions.

context --id <thing-id> --run-id <run-id>

returns the business text and version captured when execution was accepted. When the latest facts or the version before a write are needed, additionally read the live context without

--run-id

, and clearly distinguish collection time from snapshot version. If the read fails, disclose the missing data; do not infer it from the title, and do not automatically read the live data instead. For the full contract, see the CLI reference.

The fields are title, description, tags, status, assignee, and collaborators. Status is
```
open/paused/done
```
; archiving and restoration are separate actions. Description is required when creating a thing. If the assignee is omitted during creation, it defaults to the current user, while an explicit null is rejected.
Use
```
members/options
```
to query members and candidate things; creation, editing, and collaborator management follow server-side permissions. Before making a change, read the latest version. After a 409, compare the changes rather than simply replacing the version number.
Records use
```
url/note/progress
```
. If the type is omitted, the server saves a single HTTP(S) URL as a link and everything else as a note. To update progress, use
```
entry append --type progress
```
; to modify a record, use
```
entry update
```
and
```
expected-updated-at
```
, which supports changing the title, type, or body independently.
```
--clear-title
```
clears the title.
Use
```
from-message
```
to organize a thing from conversation messages, providing verified
```
conversation-id/message-id
```
values and confirmed body text. Determine whether to organize it based on the creation signals above; the user does not need to explicitly name the command. First present inferred content as a proposal in the conversation; do not use the removed persisted edit-draft command.
Use
```
conversation primary/bind/unbind
```
for the primary thing,
```
link-conversation
```
for regular references, and
```
conversations
```
to query linked conversations. Linking does not change conversation privacy or permissions.
Use progress records for stage outcomes; use notes for handoffs, clearly stating completed work, evidence, and next steps. The assignee and collaborators are the only personnel-collaboration relationships; do not make additional ownership claims.
Use
```
asset available/list/link/unlink/publish
```
for files and follow the authorization boundaries and delivery attachment closed loop described above. Unlinking a file does not delete it.
Before permanent deletion, read the latest version, explain the irrecoverability and the conversation/file retention boundaries, and use
```
delete --confirm-delete --yes
```
only after explicit confirmation. When there is a run conflict, wait; do not automatically terminate the run.
Directly perform specific changes that have received explicit authorization; do not ask again.

bash

ae-cli things create --agent-space-id <space-id> --title '接口验收' --description '验证权限与数据一致性' --format json
ae-cli things entry append --agent-space-id <space-id> --id <thing-id> --type progress --content '已完成接口联调' --format json

Use ae-things-review for reviews and ae-things-progress for periodic summaries. Both draw conclusions from a complete collection of facts while retaining indications of unread files, truncation, and non-transactional collection boundaries.

Use

things conversations

to list linked conversations and

things conversation get

to read one. Start new conversations from the workspace UI; Things CLI only manages thing links and primary-thing binding.

ae-things

NPX Install

Tags

SKILL.md Content (Chinese)