Specs

Specs were called requirements in earlier versions of Tiden. The requirements your team keeps in Jira, Linear, or Notion stay requirements: Tiden reads them, along with your code, and keeps specs as its own versioned record of what the product does. In the API, a spec is the requirement resource.

Specs describe product behavior. In Tiden, they are structured enough for traceability and agent workflows, but still editable as Markdown.

Fields

Field	Purpose
Title	Short spec name
Content	Markdown body
Type	Spec category used for filtering
Status	Backlog, Active, Review, or Done
Priority	Not set, Low, Medium, High, or Critical
Parent	Optional parent spec for hierarchy
Component	Product area used for grouping and risk
Assignee	Optional user responsible for the spec
Sources	Structured provenance attached to the spec

Spec tree

Specs can be nested. The left tree supports filtering by spec type, compact mode, branch status indicators, and direct selection by URL.

Sources

Sources preserve where a spec came from. A source can reference:

• Repository files.
• Documentation URLs.
• Manual input.
• Attachments.
• Agent artifacts.
• Other evidence.

When using the CLI, pass a JSON file with --sources-file. The file may be either an array or an object with a sources array.

{
  "sources": [
    {
      "sourceType": "documentation_url",
      "title": "Checkout PRD",
      "url": "https://example.com/prd/checkout"
    }
  ]
}

Updating a spec with --sources-file replaces the full source set. Passing an empty array clears sources.

Attachments

Attachments can be added to specs from the web UI. Use attachments for supporting files that should stay with the spec.

History and restore

Spec history lets you inspect past changes. Deleted specs can be restored through the web UI when restore is available for that item.

Branch behavior

On main, edits update the canonical spec. On a non-main branch, editing a main spec creates a branch copy. New branch specs stay branch local until merge.