Universal Metadata + Template Editor Workflow

Why this document exists

My backlog-this workflow defines the interrupt mechanism: stop building, capture the idea, and preserve momentum.

This document defines the next evolution: a reusable workflow for any document that needs structured content plus high-quality metadata.

I use backlog-this as the primary example in this doc, but the same model should also apply to other document types (notes, specs, docs, and future content templates).

The vision

When I create a structured document (using backlog-this as the first use case), I want a system that feels like this:

1. AI captures context and proposes a complete backlog item draft
2. A new browser window opens with an editor pre-filled with metadata + structured content
3. I refine the draft using both natural-language commands and traditional UI controls
4. I confirm in under 60 seconds
5. The finalized item is published to backlog storage and appears on my site

The key idea is speed plus quality: no context loss, no formatting tax, and no half-baked artifacts.

User intent behind backlog-this

backlog-this is the command that triggers the higher-fidelity flow this document proposes.

• backlog-this means: capture and immediately run through a rapid metadata/editor flow to produce a high-quality artifact

I still avoid full implementation work, but I invest one focused minute in making the entry actually excellent.

End-to-end workflow

1) Trigger detection

I say backlog-this during active work.

System response:

• freeze tangent implementation
• snapshot current context (conversation, current goal, relevant files)
• generate a draft backlog item with rich metadata and structured sections

2) Draft generation

The system prepares:

• a candidate title and slug
• categorized tags
• status and priority defaults
• a structured body template populated from context
• explicit assumptions and unresolved questions

3) Instant editor launch

A new browser window opens to a dedicated “Backlog Item Review” screen.

The screen has:

• left pane: metadata form
• center pane: structured markdown/tsx content
• right pane: AI command box + validation checklist + preview

4) Two editing modes

Natural-language editing

I can say things like:

• “make this title more specific to metadata tooling”
• “raise priority to high and add tags for ux + automation”

Traditional UI editing

I can directly edit:

• text fields
• dropdowns
• checkboxes/toggles
• reorderable section blocks
• links and related-item references

Both modes stay in sync in real time.

5) Fast validation

Before publish, system runs checks:

• required metadata present
• slug uniqueness
• date format valid
• tags normalized
• section completeness
• estimated effort + next step included

Validation should be pass/fail with plain-language fixes.

6) Confirm + publish

I click confirm.

The system:

• writes the finalized backlog item to canonical storage
• updates indexes/navigation so it appears in backlog views
• makes it visible on-site
• returns a success summary with link + slug

Experience targets

• Time to first draft: < 5 seconds
• Time to review and confirm: < 60 seconds
• Manual typing needed: minimal
• Context preservation: high confidence

Metadata schema proposal (v1)

This is the richer schema I want for backlog items.

Core identity

• title: human-readable, specific
• slug: kebab-case unique identifier
• date: creation timestamp (ISO 8601)
• updated: update timestamps
• type: doc (or future doc:backlog if needed)

Ownership + provenance

• author: item owner
• authorshipNote: AI/human collaboration note
• sourceContext: short origin summary (what conversation/task generated this)
• sourceUrl: optional external reference

Workflow state

• status: open | in-progress | done | blocked | wont-do
• priority: low | medium | high | critical
• stage: captured | validated | scheduled | active | archived
• confidence: 1-5 confidence in definition quality

Planning fields

• problemStatement: concise pain/opportunity
• outcome: desired result
• whyNow: urgency/importance justification
• whyNotNow: reason this is parked versus implemented immediately
• nextStep: smallest concrete follow-up action
• effort: xs | s | m | l | xl
• impact: low | medium | high

Relationship fields

• tags: classification keywords
• relatedPosts: related docs/posts by slug
• dependsOn: upstream dependencies by slug
• blockedBy: blocking dependencies by slug
• supersedes: older idea replaced by this one
• supersededBy: newer idea replacing this one

Traceability fields

• projectId: optional project grouping key
• feature: optional feature grouping key
• decisionRefs: links to related decisions/specs
• commitRefs: links or hashes for commits touching this idea

Publication fields

• visibility: public | private | internal
• publish: boolean toggle for site visibility
• reviewedAt: timestamp of last explicit review

Structured content template proposal (v1)

Each backlog item body should include:

1. Summary (2-4 lines)
2. Problem
3. Proposed Direction
4. Scope Boundaries (in/out)
5. Risks / Unknowns
6. Dependencies
7. Acceptance Signals (how I know this is done)
8. Next Step
9. Notes / Context Snapshot

This shape keeps entries readable and actionable.

Editor UX requirements

Required capabilities

1. AI-assisted rewrite for any selected field/section
2. One-click normalize for tags and slug
3. Real-time schema validation
4. Live preview of published rendering
5. Keyboard-first confirm flow

Nice-to-have capabilities

1. Voice-to-field capture
2. Saved metadata presets by item type
3. Duplicate-from-existing-item for recurring patterns
4. Auto-suggest related items based on semantic similarity

Failure modes and safeguards

Failure mode: over-automation creates wrong metadata

Safeguard:

• show confidence levels
• highlight inferred fields
• require explicit confirm before publish

Failure mode: flow becomes too heavy

Safeguard:

• maintain sub-60-second happy path
• provide “quick confirm” and “deep edit” modes

Failure mode: ambiguous command intent

Safeguard:

• reserve backlog-this for this editor-launch flow
• use alternate explicit commands (if added later) for lightweight capture

Relationship to lightweight capture

• backlog-this: quick capture + one-minute structured review + publish
• lightweight capture commands (optional future aliases): quick park-and-return behavior

These workflows can coexist at different fidelity levels.

Rollout strategy

Phase 1: Draft + editor shell

• Trigger parses backlog-this
• Draft metadata/body generated
• Editor opens with pre-filled content

Phase 2: Validation + publish integration

• Schema checks and inline fixes
• Persist to canonical backlog location
• Site visibility/index update

Phase 3: Intelligent refinement

• Better related-item suggestions
• Dependency graph support
• workflow analytics (capture-to-implement lead time)

Definition of done for this feature

This workflow is done when I can reliably do the following in under one minute:

1. say backlog-this
2. review AI-generated metadata + content in a dedicated editor
3. make quick NL/UI edits
4. confirm and publish a high-quality backlog entry to storage + site

At that point, backlog capture stops being a task and just becomes automatic.