Skip to main content

Syntax

Description

The feedback dismiss command marks feedback as resolved or addressed. Dismissed feedback:
  • Remains in the database (not deleted)
  • Is marked with dismissed: true
  • Updates the updated_at timestamp
  • Appears grayed out in feedback list
  • Can be filtered with --dismissed true
  • Preserves full audit trail
Use this command when:
  • You’ve addressed the feedback by updating the spec
  • The feedback is no longer relevant
  • A question has been answered
  • A suggestion has been implemented or declined
  • An implementation note has been reviewed
Dismissing is a soft operation - feedback remains in the database for historical reference. There is no way to delete feedback permanently.

Arguments

string
required
One or more feedback IDs to dismissExample: FB-001 or FB-001 FB-002 FB-003You can dismiss multiple feedback entries in a single command.

Examples

Dismiss Single Feedback

Mark one feedback as addressed:

Dismiss Multiple Feedback

Mark several feedback entries as resolved:

Dismiss After Spec Update

After updating a spec to address feedback:

Dismiss Non-Existent Feedback

Attempt to dismiss feedback that doesn’t exist:

JSON Output

Get machine-readable output:
Notice dismissed: true and the updated updated_at timestamp.

What Happens When You Dismiss

1

Dismissed flag set

The dismissed field is set to true in the database
2

Timestamp updated

The updated_at timestamp is set to the current time
3

Database updated

Changes are written to the SQLite database
4

JSONL exported

The dismissal is recorded in feedback.jsonl (if feedback export is enabled)
5

Appearance changes

Feedback appears grayed out in feedback list output

What Doesn’t Change

Dismissing feedback does NOT:
  • Delete the feedback entry
  • Change the feedback content
  • Modify the anchor location
  • Remove the feedback from the spec
  • Affect the source issue
  • Change creation timestamp
Dismissed feedback remains fully accessible and searchable.

Common Workflows

Address Feedback and Dismiss

1

Review feedback

2

View spec

3

Update spec

Edit the spec to address the feedback
4

Dismiss feedback

5

Commit changes

Bulk Dismiss After Spec Update

Dismiss all feedback for a spec you’ve updated:
1

Update spec

Make comprehensive spec improvements
2

List feedback

3

Review and dismiss

Dismiss Obsolete Feedback

Remove feedback that’s no longer relevant:
1

Find stale or outdated feedback

2

Review details

3

Dismiss if obsolete

Dismiss Implementation Notes

After reviewing implementation feedback:

Scripting Examples

Dismiss All Feedback for a Spec

Be careful with bulk dismissals - review feedback first to ensure it’s been addressed.

Dismiss All Comment-Type Feedback

Conditional Dismiss

Generate Dismissal Report

Dismiss vs Delete

Dismiss (Available)

Marks as addressed
  • Feedback retained in database
  • Full audit trail preserved
  • Can be viewed later
  • Appears in filtered lists
  • Reversible (manually update DB)

Delete (Not Available)

Permanent removal
  • Not supported by CLI
  • Would lose audit trail
  • No way to recover
  • Breaks historical context
  • Not recommended for feedback
Best practice: Always dismiss rather than delete. Feedback provides valuable historical context for how specs evolved.

Viewing Dismissed Feedback

1

List dismissed feedback

2

Show details

The status will show “Dismissed”
3

View in spec

Dismissed feedback may be hidden or grayed out

”Un-dismissing” Feedback

There’s no dedicated command to reactivate dismissed feedback. If needed:

Manual Database Update

Direct database updates are not recommended. Consider adding new feedback instead.

Better Alternative

Add new feedback instead:

Common Questions

Not through the CLI. You would need to manually update the database:
Better approach: Add new feedback if still relevant.
No, sudocode doesn’t have built-in notifications. Dismissals are tracked via git commits.
Always dismiss. There’s no delete command because feedback should be preserved for audit trail.
Dismissed feedback remains linked to specs but may be hidden or grayed out in spec show output.
No, the command doesn’t accept a reason parameter. Document dismissal reasons in git commit messages:
Check git history:
Or for JSONL:

Troubleshooting

Cause: The feedback ID doesn’t existSolution: List all feedback to find the correct ID:
Cause: Using wrong filterSolution: Show all feedback including dismissed:
Or show only dismissed:
Cause: Feedback is already dismissedSolution: Check status:
Dismissing again is harmless but has no effect.
Cause: Possible database sync issueSolution: Run sync:
Then check again:

feedback list

List all feedback

feedback show

View feedback details

feedback add

Add new feedback

spec show

View spec with feedback

issue show

View issue with feedback

Next Steps

1

Review feedback

2

Address the feedback

Update spec or respond as appropriate
3

Dismiss

4

Commit changes

Feedback System Concept Guide

Learn more about the feedback system and bidirectional learning