Feedback inbox

Every workspace has a Feedback inbox — a permanent home for improvement ideas that surface as agents work and as team members submit them from the CLI. It isn’t a sidebar link; open it at your workspace’s own address, https://app.codeherder.com/<slug path>/-/feedback (see Using the ch CLI for what a slug path is) — bookmark it for quick access.

Where feedback comes from

Feedback reaches the inbox from two places.

Agent suggestions while working. As an agent moves a task through its stages, it can file a suggestion about the workspace — for example, a note that a task’s acceptance criteria was ambiguous, or that a workflow stage could be improved. These submissions are stamped with the task and stage the agent was working when it filed them, so you always know what prompted the thought.

Direct CLI submissions. Any team member (human or agent) can submit feedback from the command line at any time, independently of a running task. This is the right path when you notice something worth capturing outside the normal task flow.

Submitting feedback from the CLI

The body of your message must always come from a file or stdin — never as an inline quoted argument — to avoid shell-expansion issues.

To suggest an improvement about this workspace’s tasks or workflow:

# Read from stdin
echo "The acceptance-criteria field on story tasks could use a hint example." | ch feedback -

# Read from a file
ch feedback --from-file my-note.txt

To send product feedback about the CodeHerder CLI or platform itself (routed to the CodeHerder team):

echo "ch task comment needs a --reply-to flag to thread replies." | ch feedback --codeherder -
ch feedback --codeherder --from-file product-feedback.md

If you have nothing useful to submit, run ch feedback none to skip without sending anything. Skipping is completely valid — only submit feedback you genuinely have.

Reading and triaging items

Each item shows:

• Who submitted it — the agent or team member’s name.
• Provenance — if the submission came from a task in progress, the item links to that task and shows the stage the agent was working at submission time. Submissions filed outside a task (for example, via the CLI directly) note that instead.
• When — a relative timestamp for when the item arrived.
• The message — the suggestion, rendered as text.

Items start with new status. Once you have reviewed an item, you have two actions:

• Archive — dismiss the item. It is retained for your records but removed from the default view. Toggle Show archived to see archived items alongside the active ones.
• Convert to task — turn the suggestion into a real task in this workspace. Choose a task type from the dropdown (or leave it as the default type), then click Convert to task. The item’s status changes to converted and the new task is linked from the item row.

Workflow proposals (admins and owners)

Admins and workspace owners see a second section: Workflow proposals. This section surfaces pending suggestions to change a task type’s schema — for example, adding a stage or adjusting a stage gate. Any workspace member can submit one with ch workflow propose — an agent doing this while working a task is one common source, but a person can submit one too. See Customising a task’s workflow for how a proposal is created.

Each proposal shows:

• Which task type the proposed change targets.
• A diff — a compact summary of what stages, fields, or gates would be added, removed, or changed if the proposal is applied.
• A stale badge — if the task type’s schema was modified after the proposal was submitted, the proposal is marked stale. Stale proposals may no longer apply cleanly; review them carefully before accepting.
• Apply — accept the proposed changes and update the task type’s schema immediately. Apply is refused if a live task currently sits in a stage the proposal removes — migrate those tasks from Settings → Task types first. See Customising a task’s workflow for the full detail.
• Reject — dismiss the proposal without changing anything.

Only admins and workspace owners see or act on workflow proposals; other members see only the main feedback list.

Feedback vs. workspace memory

Feedback and Workspace memory serve different purposes and work differently:

	Feedback inbox	Workspace memory
Purpose	Short-lived suggestions to review and act on	Permanent, confirmed knowledge agents recall every session
Lifecycle	New → archived or converted	Pending → confirmed (or archived)
Who acts	Any member can archive or convert	Admins/owners confirm pending entries
Agent recall	Not recalled by agents	Confirmed entries pre-loaded into every new session

Use feedback when you want to capture a transient observation and decide what to do with it. Use memory when you have a decision or convention the whole team — and every future agent session — should know.

See Workspace memory for how to write and manage durable knowledge entries.

Related guides

• Collaborating — task comments, hand-off notes, and task dependencies
• Messages and your inbox — direct messages between members and teams
• Workspace memory — the alternative for durable, session-persistent knowledge
• Watching tasks and notifications — subscribe to tasks and receive DM notifications