Skip to main content

Syntax

Description

The spec update command allows you to modify properties of an existing spec. You can update the title, priority, description, parent relationship, tags, and archive status. When you update a spec:
  • Changes are written to the SQLite database
  • The markdown file is updated with new frontmatter
  • Changes are exported to JSONL for version control
  • The updated_at timestamp is automatically set
Updates are partial - you only need to specify the fields you want to change. Other fields remain unchanged.

Arguments

spec-id
string
required
The ID of the spec to updateExample: SPEC-001The spec must exist in your project.

Options

--title
string
Update the spec titleExample: --title "Updated Authentication System"Changes the display title of the spec.
-p, --priority
number
Update priority level (0-4)Example: --priority 0Priority levels:
  • 0 - Critical (highest)
  • 1 - High
  • 2 - Medium
  • 3 - Low
  • 4 - Lowest
-d, --description
string
Update the spec description/contentExample: --description "Updated spec content"This replaces the markdown content of the spec.
--parent
string
Update parent spec ID for hierarchical organizationExample: --parent SPEC-005Use empty string to remove parent: --parent ""
--tags
string
Replace all tags with new comma-separated listExample: --tags "auth,security,critical"Note: This replaces all existing tags. To add/remove individual tags, edit the markdown file directly.
--archived
boolean
Archive or unarchive the specExample: --archived true or --archived falseArchived specs are hidden from default listings but retained for reference.

Examples

Update Priority

Elevate a spec to critical priority:

Update Title

Rename a spec:

Update Description

Replace spec content:

Update Multiple Fields

Change priority and title together:

Set Parent Spec

Add to hierarchy:
This makes SPEC-003 a child of SPEC-001.

Remove Parent Spec

Remove from hierarchy:

Archive a Spec

Mark spec as archived (deprecated):
Archived specs won’t appear in spec list by default.

Unarchive a Spec

Restore an archived spec:

Update Tags

Replace all tags:
The --tags option replaces ALL existing tags. To add or remove individual tags, edit the markdown file directly.

JSON Output

Use the global --json flag for machine-readable output:

Common Workflows

Promoting Spec Priority

1

List specs by priority

2

Promote to high priority

3

Verify change

Reorganizing Spec Hierarchy

1

View current structure

2

Move child specs

3

Verify hierarchy

Deprecating Old Specs

1

Archive the spec

2

Lower priority

3

Update title to indicate deprecation

Bulk Updates with Scripting

Update multiple specs programmatically:

Update Behavior

What Gets Updated

When you run spec update:
  1. Database - SQLite database is updated immediately
  2. Markdown file - Frontmatter is updated with new values
  3. JSONL - Changes are exported to specs.jsonl for version control
  4. Timestamp - updated_at is set to current time

What Doesn’t Change

  • Spec ID - Immutable, cannot be changed
  • Creation timestamp - created_at never changes
  • File path - Markdown filename stays the same
  • Relationships - Use link command to manage relationships
  • Feedback - Use feedback commands to manage feedback

Content Updates

The --description flag replaces the markdown content below the frontmatter: Before:
After sudocode spec update SPEC-001 --description "New content":
For complex content updates, edit the markdown file directly rather than using --description.

Common Questions

No, spec update works on one spec at a time. For bulk updates, use shell scripting with loops:
Relationships are unaffected by spec update. They persist regardless of changes to title, priority, or other properties.
The --tags option replaces all tags. To add tags while keeping existing ones:
  1. View current tags: sudocode spec show SPEC-001
  2. Combine old and new: sudocode spec update SPEC-001 --tags "old,tags,new,tag"
Or edit the markdown file directly to add tags to the frontmatter.
No, spec IDs are immutable. They serve as stable references across the system. If you need a different ID, create a new spec and archive the old one.
  • Archiving (--archived true) hides the spec from default listings but retains it for reference
  • Deleting (spec delete) permanently removes the spec from the database
Use archiving to deprecate specs you might need to reference later.
No, sudocode doesn’t have built-in notifications. Updates are tracked via git commits and the updated_at timestamp. Consider adding a git commit message describing significant updates.

Troubleshooting

Cause: The spec ID doesn’t existSolution: Verify the ID:
Cause: Priority must be 0-4Solution: Use a valid priority:
Cause: The parent spec ID doesn’t existSolution: Verify the parent exists:
Cause: Only database-level fields were updated, or sync issueSolution: Run sync to ensure consistency:

spec show

View spec details

spec create

Create new spec

spec list

List all specs

spec delete

Delete a spec

link

Manage relationships

sync

Synchronize data

Next Steps

1

View spec details

2

Update properties

3

Verify changes

4

Commit to git

Specs Concept Guide

Learn more about specs and their lifecycle