Skip to main content

Syntax

Description

The spec delete command permanently removes specifications from your project. This operation:
  • Deletes the spec from the SQLite database
  • Removes the markdown file from .sudocode/specs/
  • Updates the JSONL file to reflect the deletion
  • Does NOT automatically delete related issues or relationships
This operation is permanent and cannot be undone. Consider archiving specs instead if you might need to reference them later.

Arguments

string
required
One or more spec IDs to deleteExample: SPEC-001 or SPEC-001 SPEC-002 SPEC-003You can delete multiple specs in a single command by providing multiple IDs.

Examples

Delete a Single Spec

Remove one spec:

Delete Multiple Specs

Remove several specs at once:

Delete Non-Existent Spec

Attempt to delete a spec that doesn’t exist:
When deleting multiple specs, valid deletions proceed even if some IDs don’t exist:

JSON Output

Get machine-readable output:

What Gets Deleted

When you delete a spec:
1

Database record removed

The spec is deleted from the SQLite specs table
2

Markdown file removed

The .md file in .sudocode/specs/ is deleted
3

JSONL updated

The deletion is recorded in specs.jsonl
4

Tags cleaned up

Tags associated with the spec are removed

What Doesn’t Get Deleted

The following are NOT automatically deleted:
Relationships to/from the deleted spec remain in the database as orphaned entries. This is by design to preserve relationship history.Impact: Issues or other specs that reference the deleted spec will show broken relationships.Solution: Manually remove relationships before deleting, or clean them up afterward.
Issues that implement the deleted spec are not deleted. They remain in the database with an implements relationship pointing to a non-existent spec.Impact: These issues become orphaned.Solution: Close or reassign these issues before deleting the spec:
Feedback provided to the spec is not automatically deleted.Impact: Feedback entries remain but point to a non-existent spec.Solution: Review and dismiss feedback before deleting:
If the deleted spec is a parent, child specs are not deleted. They become orphaned with invalid parent_id references.Impact: Child specs lose their parent relationship.Solution: Update or delete child specs first:

Safe Deletion Workflow

Follow these steps to safely delete a spec:
1

Review spec details

Check for:
  • Incoming relationships (issues implementing it)
  • Outgoing relationships (specs it depends on)
  • Child specs (if it’s a parent)
  • Feedback received
2

Handle relationships

Close or update related issues:
Update child specs:
3

Address feedback

Dismiss any open feedback:
4

Delete the spec

5

Verify deletion

Alternative: Archive Instead of Delete

Consider archiving instead of deleting:
Benefits of archiving:
  • Spec is hidden from default listings
  • Historical reference is preserved
  • Relationships remain intact
  • Can be unarchived if needed
When to delete vs archive:
  • Delete: Duplicate specs, test specs, genuinely wrong/useless content
  • Archive: Deprecated features, superseded designs, historical documentation

Common Workflows

Cleaning Up Old Specs

1

List deprecated specs

2

Review each spec

3

Close related issues

4

Delete the specs

Bulk Delete with Scripting

Delete all archived specs:
Delete all low-priority specs:
Be very careful with bulk deletions. Always review specs before deleting.

Recovering from Accidental Deletion

If you accidentally delete a spec:
1

Check git history

2

Restore from git

3

Or restore from backup

If you have backups of .sudocode/, restore the database and JSONL files
This is why sudocode uses git-tracked JSONL files as the source of truth. You can always recover from git history.

Common Questions

No, spec delete executes immediately without confirmation. Be careful with this command.For safety, you could create a shell alias that prompts for confirmation:
Not directly, but you can recover from git:
This restores the JSONL file from the previous commit and re-imports it.
The issues remain in the database, but their implements relationship points to a non-existent spec. This creates an orphaned relationship.Best practice: Close or update these issues before deleting the spec.
Archive for:
  • Superseded designs you might reference later
  • Historical documentation
  • Deprecated features still in use
Delete for:
  • Duplicate/accidental specs
  • Test/temporary specs
  • Genuinely incorrect content
Not directly, but you can use scripting:
Always review the list before executing!
No, child specs are not automatically deleted. They become orphaned with invalid parent_id references.Update children first:

Troubleshooting

Cause: The spec ID doesn’t existSolution: Verify the ID:
Cause: Database or file system errorSolution:
  1. Check database isn’t locked by another process
  2. Verify file permissions on .sudocode/ directory
  3. Try syncing first: sudocode sync
Cause: Cache or sync issueSolution: Run sync to ensure consistency:
Cause: File deletion failed but database updatedSolution: Manually remove the file:

spec list

List all specs

spec show

View spec details

spec update

Update spec (archive instead)

issue close

Close related issues

feedback dismiss

Dismiss feedback

sync

Synchronize data

Next Steps

1

Review the spec

2

Consider archiving instead

3

If deleting, clean up relationships

Close issues, dismiss feedback, update children
4

Delete the spec

5

Commit changes

Specs Concept Guide

Learn more about specs and their lifecycle