Skip to content
atomize
GitHub

Templates

Example Templates

Development docs · main. Your installed version may differ.

Real-world Atomize template examples. Each file is a working template you can validate immediately and dry-run against either matching work items or explicit mock stories.

Files

Section titled “Files”
FileWhat it demonstrates
backend.atomize.yamlStandard backend API workflow with task dependencies
frontend.yamlReact component development workflow
fullstack.atomize.yamlCombined backend + frontend with a branching task graph
conditional-dependencies-template.atomize.yamlConditional tasks: tasks that only appear when a story meets specific criteria
conditional-percentage-template.atomize.yamlConditional estimation: task weights that adapt to story size and tags
advanced-filtering.atomize.yamlFull filter criteria showcase: state exclusion, historical states, area/iteration hierarchy, date filters, team override
custom-location.atomize.yamlA template stored outside a standard templates//atomize/ directory: the .atomize.yaml extension alone is a durable VS Code opt-in regardless of file location
points-to-hours.atomize.yamlEstimation conversion with a factor: 1 story point = 4 hours, plus rounding, a minimum, and skipping unestimated Stories
fibonacci-hours-table.atomize.yamlA numeric conversion table for points that don't scale linearly, with a default Story Estimate and a point-based condition
tshirt-size-estimation.atomize.yamlT-shirt sizes from a custom picklist field: source, a size table, fractional sizes like 0.5XL, and size conditions
custom-fields-and-task-type.atomize.yamlA customised process: categorical complexity in, a custom child work item type (taskType) and effort field (targetFields) out
repeated-review-tasks.atomize.yamlOne review Task per developer from a single definition with repeat, alongside ordinary dependent tasks

backend.atomize.yaml

Section titled “backend.atomize.yaml”

A production-ready backend API template. Covers the full development cycle from API design through code review, with dependencies enforcing a logical order.

Matches: User Stories and Product Backlog Items tagged backend or api, in states New, Approved, or Active, that don't already have tasks.

Tasks (6):

  1. Design API Specification: 10%
  2. Database Schema Changes: 20%
  3. Implement Business Logic: 35% (depends on design + schema)
  4. Unit & Integration Tests: 20% (depends on implementation)
  5. API Documentation: 5%
  6. Code Review & Refinement: 10%

Try it:

Terminal window
atomize validate examples/backend.atomize.yaml
atomize generate examples/backend.atomize.yaml --platform mock
examples/backend.atomize.yaml
formatVersion: "1.0"
name: "Backend API Feature"
description: "Standard tasks for backend API development"
author: "Atomize"
tags: ["backend", "api", "standard"]


# Filter to identify applicable User Stories
filter:
  workItemTypes:
    - "User Story"
  excludeIfHasTasks: true


# Task template with estimation percentages
tasks:
  - id: "design-api"
    title: "Design API Specification"
    description: |
      Design RESTful API endpoints following company standards:
      - Define request/response models
      - Document in OpenAPI/Swagger
      - Review with team architect
    estimationPercent: 10
    tags: ["design", "api"]
    activity: "Design"


  - id: "database-schema"
    title: "Database Schema Changes"
    description: |
      Design and implement database changes:
      - Create/update migrations
      - Define models and relationships
      - Index optimization
    estimationPercent: 20
    tags: ["database", "backend"]
    activity: "Development"


  - id: "implement-logic"
    title: "Implement Business Logic"
    description: |
      Core API implementation:
      - Implement service layer
      - Add validation logic
      - Error handling
      - Logging
    estimationPercent: 35
    tags: ["implementation", "backend"]
    activity: "Development"
    dependsOn:
      - "design-api"
      - "database-schema"


  - id: "unit-tests"
    title: "Unit & Integration Tests"
    description: |
      Comprehensive test coverage:
      - Unit tests (80%+ coverage)
      - Integration tests
      - Mock external dependencies
    estimationPercent: 20
    tags: ["testing", "quality"]
    activity: "Testing"
    dependsOn:
      - "implement-logic"


  - id: "documentation"
    title: "API Documentation"
    description: |
      Update documentation:
      - API endpoint documentation
      - Update README
      - Code comments
      - Postman collection
    estimationPercent: 5
    tags: ["documentation"]
    activity: "Documentation"


  - id: "code-review"
    title: "Code Review & Refinement"
    description: |
      Review and refine:
      - Create pull request
      - Address review feedback
      - Final testing
    estimationPercent: 10
    tags: ["review", "quality"]
    activity: "Design"


# Estimation strategy
estimation:
  strategy: "percentage"
  source: "Microsoft.VSTS.Scheduling.StoryPoints"
  rounding: "nearest"
  minimumTaskEstimate: 0.5


# Validation rules
validation:
  totalEstimationMustBe: 100
  minTasks: 4
  maxTasks: 10


# Metadata
metadata:
  category: "Backend Development"
  estimationGuidelines: |
    Use this template for stories sized 3-13 points.
    For larger stories, consider breaking down first.

frontend.yaml

Section titled “frontend.yaml”

A React component development template covering the full UI lifecycle including accessibility testing.

Matches: User Stories tagged frontend or react, in states New or Approved, without existing tasks.

Tasks (6):

  1. UI/UX Design Review: 10%
  2. Component Structure & Setup: 15%
  3. Component Logic Implementation: 30% (depends on structure)
  4. Styling & Responsive Design: 20%
  5. Accessibility Testing: 10%
  6. Component Testing: 15% (depends on logic)

Try it:

Terminal window
atomize validate examples/frontend.yaml
atomize generate examples/frontend.yaml --platform mock
examples/frontend.yaml
# atomize-yaml
formatVersion: "1.0"
name: "Frontend React Feature"
description: "Standard tasks for React component development"
author: "Atomize"
tags: ["frontend", "react", "ui"]


filter:
  workItemTypes:
    - "User Story"
  states:
    - "New"
    - "Approved"
  tags:
    include:
      - "frontend"
      - "react"
  excludeIfHasTasks: true


tasks:
  - id: "ui-design-review"
    title: " UI/UX Design Review"
    description: |
      Review designs and create implementation plan:
      - Review Figma/design specs
      - Identify reusable components
      - Plan component hierarchy
      - Clarify interactions and states
    estimationPercent: 10
    tags: ["design", "planning"]
    activity: "Design"


  - id: "component-structure"
    title: "Component Structure & Setup"
    description: |
      Set up component architecture:
      - Create component files
      - Define props interfaces
      - Set up state management
      - Configure routing (if needed)
    estimationPercent: 15
    tags: ["setup", "architecture"]
    activity: "Development"


  - id: "component-logic"
    title: "Component Logic Implementation"
    description: |
      Implement core functionality:
      - Business logic
      - Event handlers
      - API integration
      - Form validation
    estimationPercent: 30
    tags: ["implementation", "logic"]
    activity: "Development"
    dependsOn:
      - "component-structure"


  - id: "styling"
    title: "Styling & Responsive Design"
    description: |
      Apply styles and ensure responsiveness:
      - CSS/Tailwind implementation
      - Mobile responsiveness
      - Theme integration
      - Dark mode (if applicable)
    estimationPercent: 20
    tags: ["styling", "css", "responsive"]
    activity: "Development"


  - id: "accessibility"
    title: "Accessibility Testing"
    description: |
      Ensure WCAG 2.1 AA compliance:
      - Keyboard navigation
      - Screen reader testing
      - ARIA labels
      - Color contrast
      - Focus management
    estimationPercent: 10
    tags: ["accessibility", "a11y", "quality"]
    activity: "Testing"


  - id: "component-tests"
    title: "Component Testing"
    description: |
      Write comprehensive tests:
      - Jest unit tests
      - React Testing Library
      - Test user interactions
      - Snapshot tests
    estimationPercent: 15
    tags: ["testing", "quality"]
    activity: "Testing"
    dependsOn:
      - "component-logic"


# Estimation configuration
estimation:
  strategy: "percentage"
  source: "Microsoft.VSTS.Scheduling.StoryPoints"
  rounding: "nearest"
  minimumTaskEstimate: 0.5


# Validation
validation:
  totalEstimationMustBe: 100
  minTasks: 4


# Metadata
metadata:
  category: "Frontend Development"
  estimationGuidelines: |
    Best for stories sized 3-8 points.
    Complex UIs with animations may need additional tasks.

fullstack.atomize.yaml

Section titled “fullstack.atomize.yaml”

A combined backend + frontend template for end-to-end features. Uses a branching dependency graph where the backend and frontend tracks run in parallel after the design phase, then converge at integration.

Matches: User Stories tagged fullstack, in states New or Active, without existing tasks.

Tasks (9):

  1. Technical Design: 10%
  2. Backend API Implementation: 20% (depends on design)
  3. Database Implementation: 15% (conditional: only if story has database tag)
  4. Backend Tests: 10% (depends on backend API)
  5. Frontend Components: 20% (depends on design)
  6. Styling & Responsive Design: 10%
  7. Frontend Tests: 8% (depends on frontend components)
  8. Frontend-Backend Integration: 12% (depends on both tracks)
  9. Documentation: 5%

Try it:

Terminal window
atomize validate examples/fullstack.atomize.yaml
atomize generate examples/fullstack.atomize.yaml --platform mock --story STORY-004
examples/fullstack.atomize.yaml
formatVersion: "1.0"
name: "Fullstack Feature"
description: "Complete fullstack feature with frontend and backend tasks"
author: "Atomize"
tags: ["fullstack", "frontend", "backend"]


filter:
  workItemTypes:
    - "User Story"
  states:
    - "New"
    - "Active"
  tags:
    include:
      - "fullstack"
  excludeIfHasTasks: true


tasks:
  # Design Phase
  - id: "design-overview"
    title: "Technical Design"
    description: |
      Create comprehensive technical design:
      - Architecture diagram
      - API contract definition
      - Data models
      - UI/UX flow
    estimationPercent: 10
    tags: ["design", "planning"]
    activity: "Design"


  # Backend Tasks
  - id: "backend-api"
    title: " Backend API Implementation"
    description: |
      Implement backend API:
      - API endpoints
      - Business logic
      - Validation
      - Error handling
    estimationPercent: 20
    tags: ["backend", "api"]
    activity: "Development"
    dependsOn: ["design-overview"]


  - id: "database"
    title: "Database Implementation"
    description: |
      Database changes:
      - Schema migrations
      - Models
      - Queries
      - Indexes
    estimationPercent: 15
    tags: ["database", "backend"]
    activity: "Development"
    condition:
      field: tags
      operator: contains
      value: database


  - id: "backend-tests"
    title: "Backend Tests"
    description: |
      Backend test coverage:
      - Unit tests (80%+)
      - Integration tests
      - API endpoint tests
    estimationPercent: 10
    tags: ["testing", "backend"]
    activity: "Testing"
    dependsOn: ["backend-api"]


  # Frontend Tasks
  - id: "frontend-components"
    title: "Frontend Components"
    description: |
      Build React components:
      - Component structure
      - Props interfaces
      - State management
      - Event handlers
    estimationPercent: 20
    tags: ["frontend", "react"]
    activity: "Development"
    dependsOn: ["design-overview"]


  - id: "frontend-styling"
    title: "Styling & Responsive Design"
    description: |
      Apply styles:
      - CSS/Tailwind
      - Mobile responsive
      - Theme integration
    estimationPercent: 10
    tags: ["frontend", "styling"]
    activity: "Development"


  - id: "frontend-tests"
    title: "Frontend Tests"
    description: |
      Frontend test coverage:
      - Component tests
      - User interaction tests
      - Snapshot tests
    estimationPercent: 8
    tags: ["testing", "frontend"]
    activity: "Testing"
    dependsOn: ["frontend-components"]


  # Integration
  - id: "integration"
    title: "Frontend-Backend Integration"
    description: |
      Connect frontend to backend:
      - API integration
      - Error handling
      - Loading states
      - Data flow testing
    estimationPercent: 12
    tags: ["integration"]
    activity: "Development"
    dependsOn: ["backend-api", "frontend-components"]


  # Documentation & Review
  - id: "documentation"
    title: "Documentation"
    description: |
      Complete documentation:
      - API documentation
      - Component documentation
      - README updates
      - Deployment guide
    estimationPercent: 5
    tags: ["documentation"]
    activity: "Documentation"


# Estimation configuration
estimation:
  strategy: "percentage"
  source: "Microsoft.VSTS.Scheduling.StoryPoints"
  rounding: "nearest"
  minimumTaskEstimate: 0.5


# Validation
validation:
  totalEstimationRange:
    min: 95
    max: 105
  minTasks: 5


# Metadata
metadata:
  category: "Fullstack Development"
  estimationGuidelines: |
    Best for stories sized 5-13 points.
    This template covers both frontend and backend.
    Adjust tasks based on complexity.

conditional-dependencies-template.atomize.yaml

Section titled “conditional-dependencies-template.atomize.yaml”

Demonstrates conditional tasks: tasks that are only created when a story meets specific criteria. When a conditional task is skipped, its estimation is redistributed to the remaining tasks.

Matches: User Stories tagged development.

Key features shown:

  • condition field with tag-based rules (CONTAINS "backend", CONTAINS "frontend", CONTAINS "security")
  • condition with compound logic (AND, OR, NOT CONTAINS)
  • condition based on numeric fields (${story.estimation} >= 13)
  • Dependencies that span conditional tasks (e.g., unit-tests depends on backend-api and frontend-ui: whichever were created)

Tasks (9, most conditional):

TaskCreated when
UI/UX DesignAlways
Backend APIStory has backend tag
Frontend UIStory has frontend tag
Accessibility TestingStory has frontend tag OR doesn't have legacy tag
Security ReviewStory has security tag AND priority ≤ 2
Unit TestsAlways (depends on whichever of backend/frontend exist)
Integration TestsAlways (depends on unit tests)
Performance TestingStory estimation ≥ 13 points
DocumentationAlways (depends on unit tests)
DeploymentAlways (depends on integration tests + docs)

Try it:

Terminal window
atomize validate examples/conditional-dependencies-template.atomize.yaml
atomize generate examples/conditional-dependencies-template.atomize.yaml --platform mock --story STORY-004
examples/conditional-dependencies-template.atomize.yaml
formatVersion: "1.0"
name: "Full-Stack Development with Conditional Tasks"
description: "Template demonstrating conditional tasks and dependencies"


filter:
  workItemTypes:
    - "User Story"
  tags:
    include:
      - "development"


estimation:
  rounding: "nearest"
  minimumTaskEstimate: 0.5


tasks:
  # Phase 1: Design (always runs)
  - id: "design"
    title: "UI/UX Design and Mockups"
    description: "Create design mockups for ${story.title}"
    estimationPercent: 15
    activity: "Design"
    assignTo: "@ParentAssignee"
    tags:
      - "design"


  # Phase 2: Backend (conditional - only if story has backend tag)
  - id: "backend-api"
    title: "Backend API Implementation"
    description: "Implement REST API endpoints for ${story.title}"
    estimationPercent: 30
    activity: "Development"
    dependsOn: ["design"]
    condition:
      field: tags
      operator: contains
      value: backend
    tags:
      - "backend"
      - "api"


  # Phase 3: Frontend (conditional - only if story has frontend tag)
  - id: "frontend-ui"
    title: "Frontend UI Implementation"
    description: "Build user interface for ${story.title}"
    estimationPercent: 35
    activity: "Development"
    dependsOn: ["design"]
    condition:
      field: tags
      operator: contains
      value: frontend
    tags:
      - "frontend"


  # Accessibility testing (conditional - only for frontend stories without legacy tag)
  - id: "accessibility-testing"
    title: "Accessibility Testing (WCAG)"
    description: "Ensure UI meets accessibility standards for ${story.title}"
    estimationPercent: 7
    activity: "Testing"
    dependsOn: ["frontend-ui"]
    condition:
      any:
        - field: tags
          operator: contains
          value: frontend
        - field: tags
          operator: not-contains
          value: legacy
    tags:
      - "accessibility"
      - "testing"


  # Security tasks (conditional - only for high-priority stories with security tag)
  - id: "security-review"
    title: "Security Review and Audit"
    description: "Perform security review for ${story.title}"
    estimationPercent: 8
    activity: "Testing"
    dependsOn: ["backend-api", "frontend-ui"]
    condition:
      all:
        - field: tags
          operator: contains
          value: security
        - field: priority
          operator: lte
          value: 2
    priority: 1
    tags:
      - "security"


  # Phase 4: Testing (depends on what was implemented)
  - id: "unit-tests"
    title: "Unit Tests"
    description: "Write unit tests for ${story.title}"
    estimationPercent: 15
    activity: "Testing"
    dependsOn: ["backend-api", "frontend-ui"]
    tags:
      - "testing"


  - id: "integration-tests"
    title: "Integration Tests"
    description: "Write integration tests for ${story.title}"
    estimationPercent: 12
    activity: "Testing"
    dependsOn: ["unit-tests"]
    tags:
      - "testing"


  # Performance testing (conditional - only for stories with high estimation)
  - id: "performance-tests"
    title: "Performance and Load Testing"
    description: "Conduct performance testing for ${story.title}"
    estimationPercent: 10
    activity: "Testing"
    dependsOn: ["integration-tests"]
    condition:
      field: estimation
      operator: gte
      value: 13
    tags:
      - "performance"


  # Phase 5: Documentation (always runs, depends on everything)
  - id: "documentation"
    title: "Technical Documentation"
    description: "Write technical documentation for ${story.title}"
    estimationPercent: 8
    activity: "Documentation"
    dependsOn: ["unit-tests"]
    tags:
      - "documentation"


  # Deployment (final step, depends on all testing)
  - id: "deployment"
    title: "Deploy to Staging"
    description: "Deploy ${story.title} to staging environment"
    estimationPercent: 5
    activity: "Deployment"
    dependsOn: ["integration-tests", "documentation"]
    tags:
      - "deployment"

conditional-percentage-template.atomize.yaml

Section titled “conditional-percentage-template.atomize.yaml”

Demonstrates estimationPercentCondition: each task's percentage of the story adapts based on the story's size and tags. This is useful when the same task represents different amounts of work depending on story complexity.

Matches: All User Stories without existing tasks.

Key features shown:

  • estimationPercentCondition on multiple tasks
  • First-match-wins rule evaluation order
  • Conditional task combined with conditional estimation (the frontend-impl task is both conditional and has an adaptive percentage)
  • Normalization using resolved conditional percentages as the baseline (not static fallbacks)

Tasks (5):

TaskDefault %Conditional rules
Technical Design10%≥ 13 pts → 20%, ≥ 5 pts → 15%
Backend Implementation60%fullstack tag → 40%, ≥ 5 pts → 50%
Frontend Implementation30%complex-ui tag → 40%: only created for fullstack stories
Testing & QA20%critical + ≥ 8 pts → 30%, critical alone → 25%
Code Review5%Always 5%

Scenarios and their resolved splits (before normalization):

ScenarioDesignBackendFrontendTestingReviewTotal
Small backend (< 5 pts)10%60%:20%5%95%
Medium backend (5–12 pts)15%50%:20%5%90%
Medium fullstack (5–12 pts)15%40%30%20%5%110%
Large critical fullstack (≥ 13 pts, critical)20%40%30%30%5%125%

All totals are normalized to exactly 100% at generation time.

Try it:

Terminal window
atomize validate examples/conditional-percentage-template.atomize.yaml
atomize generate examples/conditional-percentage-template.atomize.yaml --platform mock
examples/conditional-percentage-template.atomize.yaml
formatVersion: "1.0"
name: "Story-Aware Task Allocation"
description: >
  Demonstrates estimationPercentCondition: each task's weight adapts to
  the story's size and tags. When the conditional frontend-impl task is
  skipped, the remaining tasks carry their already-resolved conditional
  percents into normalization, so the final split is always accurate.
author: "Atomize"
tags: ["demo", "conditional-percent", "adaptive"]


filter:
  workItemTypes:
    - "User Story"
  excludeIfHasTasks: true


estimation:
  strategy: "percentage"
  rounding: "nearest"
  minimumTaskEstimate: 0.5


tasks:
  # ── Design ────────────────────────────────────────────────────────────────
  # Allocation scales with story size.
  # Small stories (< 5 pts):  10 %  (quick design, no surprises expected)
  # Medium stories (5–12 pts): 15 %  (moderate up-front work)
  # Large stories (≥ 13 pts):  20 %  (epic-scale requires thorough design)
  - id: "design"
    title: "Technical Design & Architecture"
    description: "Define architecture, API contracts, and data models for ${story.title}"
    activity: "Design"
    assignTo: "@ParentAssignee"
    estimationPercent: 10
    estimationPercentCondition:
      - condition:
          field: estimation
          operator: gte
          value: 13
        percent: 20
      - condition:
          field: estimation
          operator: gte
          value: 5
        percent: 15
    tags: ["design"]


  # ── Backend implementation ─────────────────────────────────────────────────
  # Rules evaluated in order; first match wins.
  #
  # • fullstack tag present  → 40 %  (budget shared with the frontend task)
  # • medium/large story     → 50 %  (more surface area to cover carefully)
  # • fallback               → 60 %  (small, pure-backend story)
  - id: "backend-impl"
    title: "Backend Implementation"
    description: "Implement API endpoints and business logic for ${story.title}"
    activity: "Development"
    assignTo: "@ParentAssignee"
    dependsOn: ["design"]
    estimationPercent: 60
    estimationPercentCondition:
      - condition:
          field: tags
          operator: contains
          value: fullstack
        percent: 40
      - condition:
          field: estimation
          operator: gte
          value: 5
        percent: 50
    tags: ["backend"]


  # ── Frontend implementation (conditional task) ─────────────────────────────
  # Only created when the story is tagged "fullstack".
  # When this task is SKIPPED, the remaining tasks' resolved conditional
  # percents are used as the baseline for normalization, so Design and
  # Backend get accurate relative weights rather than stale static values.
  #
  # complex-ui tag → extra allocation for non-trivial UIs
  - id: "frontend-impl"
    title: "Frontend Implementation"
    description: "Build UI components and integrate with the API for ${story.title}"
    activity: "Development"
    assignTo: "@ParentAssignee"
    dependsOn: ["design"]
    condition:
      field: tags
      operator: contains
      value: fullstack
    estimationPercent: 30
    estimationPercentCondition:
      - condition:
          field: tags
          operator: contains
          value: complex-ui
        percent: 40
    tags: ["frontend"]


  # ── Testing & QA ──────────────────────────────────────────────────────────
  # Critical stories need more thorough test coverage.
  # AND-condition is checked first: critical + large ≥ 8 pts → 30 %
  # If only critical (smaller story)                        → 25 %
  # Otherwise                                               → 20 %
  - id: "testing"
    title: "Testing & QA"
    description: "Write automated tests and perform QA for ${story.title}"
    activity: "Testing"
    assignTo: "@ParentAssignee"
    dependsOn: ["backend-impl"]
    estimationPercent: 20
    estimationPercentCondition:
      - condition:
          all:
            - field: tags
              operator: contains
              value: critical
            - field: estimation
              operator: gte
              value: 8
        percent: 30
      - condition:
          field: tags
          operator: contains
          value: critical
        percent: 25
    tags: ["testing"]


  # ── Code review ────────────────────────────────────────────────────────────
  # Always 5 %: lightweight overhead regardless of story size or tags.
  # No estimationPercentCondition needed here.
  - id: "code-review"
    title: "Code Review & Documentation"
    description: "Peer review and document all changes for ${story.title}"
    activity: "Documentation"
    assignTo: "@ParentAssignee"
    dependsOn: ["testing"]
    estimationPercent: 5
    tags: ["review", "documentation"]


# ── Metadata ─────────────────────────────────────────────────────────────────
metadata:
  category: "Demo"
  estimationGuidelines: |
    Effective resolved percentages by scenario (before normalization):


    Scenario A: small backend-only story (< 5 pts, no "fullstack" tag):
      design=10  backend=60  testing=20  review=5  → total=95 → normalised to 100
    Scenario B: medium backend-only story (5/12 pts):
      design=15  backend=50  testing=20  review=5  → total=90 → normalised to 100
    Scenario C: medium fullstack story (5/12 pts, "fullstack" tag):
      design=15  backend=40  frontend=30  testing=20  review=5  → total=110 → normalised
    Scenario D: large critical fullstack story (≥ 13 pts, "critical" + "fullstack" tags):
      design=20  backend=40  frontend=30  testing=30  review=5  → total=125 → normalised
    Scenario E: medium critical backend-only story (5/12 pts, "critical", no "fullstack"):
      design=15  backend=50  testing=25  review=5  → total=95 → normalised to 100


    Key behaviour: when frontend-impl is skipped (no "fullstack" tag) the
    remaining tasks already hold their *resolved* conditional percents before
    normalization runs, so the final ratio reflects the per-story adjustments
    rather than the static fallback values.

advanced-filtering.atomize.yaml

Section titled “advanced-filtering.atomize.yaml”

A reference template that demonstrates every available filter option. Use it as a starting point when you need precise control over which work items Atomize processes.

Key features shown:

FilterWhat it does
teamOverrides the team from the selected Azure DevOps profile for this template
statesExcludeExcludes items in Done, Removed, or Won't Fix
statesWereEverMatches items that passed through In Review historically
areaPathsUnderMatches MyProject\Backend and all sub-areas (hierarchy traversal)
iterationsUnderMatches all sprints under Release 3 (not just one sprint)
changedAfterOnly items touched in the last 14 days (@Today-14)
createdAfterOnly items created in the last 90 days (@Today-90)

Supported @Today macro syntax:

  • @Today: start of today
  • @Today-N: N days in the past (e.g. @Today-7)
  • @Today+N: N days in the future
  • Also: @StartOfWeek, @StartOfMonth, @StartOfYear (with optional offsets)

Try it:

Terminal window
atomize validate examples/advanced-filtering.atomize.yaml
atomize generate examples/advanced-filtering.atomize.yaml --platform mock --story STORY-001


# Dry-run the estimation configuration examples
for f in examples/points-to-hours.atomize.yaml examples/fibonacci-hours-table.atomize.yaml examples/tshirt-size-estimation.atomize.yaml examples/custom-fields-and-task-type.atomize.yaml; do
  atomize generate "$f" --platform mock --story STORY-003 STORY-005
done
examples/advanced-filtering.atomize.yaml
formatVersion: "1.0"
name: "Advanced Filtering Demo"
description: |
  Demonstrates the full range of filter criteria: state exclusion, historical
  state matching, area/iteration hierarchy traversal, date-based filters, and
  team override.
author: "Atomize"
tags: ["demo", "filtering", "advanced"]
# Each option below is independent; in a real template you would only use
# the subset that makes sense for your workflow.
filter:
  # Override the team from the selected Azure DevOps profile
  team: "Backend Team"
  workItemTypes:
    - "User Story"


  # Items currently in these states
  states:
    - "Active"
    - "In Progress"


  # Exclude items in these states (complements `states`)
  statesExclude:
    - "Done"
    - "Removed"
    - "Won't Fix"


  # Items that passed through code review at some point (historical match)
  statesWereEver:
    - "In Review"


  tags:
    include:
      - "backend"
    exclude:
      - "deprecated"
      - "on-hold"


  # Match items under "MyProject\Backend" and ALL its sub-areas
  areaPathsUnder:
    - "MyProject\\Backend"


  # Match items in the current sprint or any sprint under the current release
  iterations:
    - "@CurrentIteration"
  iterationsUnder:
    - "MyProject\\Release 3"


  # Only items assigned to the person running the command
  assignedTo:
    - "@Me"


  # Only items touched in the last 14 days
  changedAfter: "@Today-14"


  # Only items created in the last 90 days
  createdAfter: "@Today-90"


  priority:
    min: 1
    max: 2


  excludeIfHasTasks: true


tasks:
  - id: "design"
    title: "Design: ${story.title}"
    description: "Technical design and approach"
    estimationPercent: 15
    activity: "Design"
    assignTo: "@ParentAssignee"


  - id: "implement"
    title: "Implement: ${story.title}"
    description: "Core implementation"
    estimationPercent: 55
    activity: "Development"
    assignTo: "@ParentAssignee"
    dependsOn:
      - "design"


  - id: "tests"
    title: "Tests"
    description: "Unit and integration tests"
    estimationPercent: 20
    activity: "Testing"
    dependsOn:
      - "implement"


  - id: "review"
    title: "Code Review & Documentation"
    estimationPercent: 10
    activity: "Documentation"
    dependsOn:
      - "tests"


estimation:
  strategy: "percentage"
  rounding: "nearest"
  minimumTaskEstimate: 0.5


validation:
  totalEstimationMustBe: 100
  minTasks: 3


metadata:
  category: "Demo"
  estimationGuidelines: "Tasks here are illustrative: adjust percentages to fit your team's workflow."

custom-location.atomize.yaml

Section titled “custom-location.atomize.yaml”

Demonstrates that the .atomize.yaml file extension alone is a durable Atomize YAML opt-in in VS Code: schema hovers, completions, and diagnostics work regardless of where the file lives, not just inside a templates/ or atomize/ directory.

Matches: User Stories in states New or Active, without existing tasks.

Tasks (2):

  1. Implement: 70%
  2. Test: 30% (depends on implementation)

Try it:

Terminal window
atomize validate examples/custom-location.atomize.yaml
atomize generate examples/custom-location.atomize.yaml --platform mock
examples/custom-location.atomize.yaml
name: "Custom Location Template"
description: "Example template stored outside a standard templates/ or atomize/ directory. The .atomize.yaml extension is detected by the VS Code extension as a durable opt-in regardless of where this file lives, enabling schema autocomplete and validation without relying on the file's path."
author: "Atomize"
tags: ["template", "example"]


filter:
  workItemTypes: ["User Story"]
  states: ["New", "Active"]
  excludeIfHasTasks: true


tasks:
  - id: "implement"
    title: "Implement: ${story.title}"
    description: "Implement the feature according to the agreed design."
    estimationPercent: 70
    activity: "Development"
    assignTo: "@ParentAssignee"


  - id: "test"
    title: "Test: ${story.title}"
    description: "Write and execute tests to validate the feature against acceptance criteria."
    estimationPercent: 30
    activity: "Testing"
    dependsOn: ["implement"]


estimation:
  strategy: "percentage"
  rounding: "none"
  ifParentHasNoEstimation: "warn"


validation:
  totalEstimationMustBe: 100

points-to-hours.atomize.yaml

Section titled “points-to-hours.atomize.yaml”

The simplest Estimation Conversion: every story point is worth the same number of hours. The Story Estimate is read from the platform default (on Azure DevOps: Story Points, then Effort, then Size), multiplied by the factor, and then split across tasks by percentage. Rounding and the minimum apply to each task afterwards.

Key features shown: conversion.factor, rounding, minimumTaskEstimate, ifParentHasNoEstimation: skip.

StoryConvertedDesign 10%Implement 60%Test 25%Review 5%
3 points12 h1 h7 h3 h0.5 h
13 points52 h5 h31 h13 h2.5 h

Try it:

Terminal window
atomize validate examples/points-to-hours.atomize.yaml
atomize generate examples/points-to-hours.atomize.yaml --platform mock --story STORY-003 STORY-005
examples/points-to-hours.atomize.yaml
# Story points → Task hours with a single conversion factor.
#
# The Story Estimate is read from the platform default (on Azure DevOps:
# Story Points, then Effort, then Size), multiplied by the factor, and then
# split across the tasks by percentage. Rounding and the minimum apply to each
# task afterwards.
#
#   5-point Story × 4 = 20 hours → Implement 60% = 12 h, Test 25% = 5 h, ...
formatVersion: "1.0"
name: "Points to Hours"
description: "Converts story points to task hours with a fixed factor (1 point = 4 hours)."
author: "Atomize"
tags: ["estimation", "factor"]


filter:
  workItemTypes: ["User Story"]
  excludeIfHasTasks: true


tasks:
  - id: "design"
    title: "Design: ${story.title}"
    estimationPercent: 10
    activity: "Design"


  - id: "implement"
    title: "Implement: ${story.title}"
    estimationPercent: 60
    activity: "Development"
    dependsOn: ["design"]


  - id: "test"
    title: "Test: ${story.title}"
    estimationPercent: 25
    activity: "Testing"
    dependsOn: ["implement"]


  - id: "review"
    title: "Code review"
    estimationPercent: 5
    activity: "Development"
    dependsOn: ["implement"]


estimation:
  strategy: "percentage"
  conversion:
    factor: 4                    # 1 story point = 4 hours
  rounding: "nearest"            # each task rounded to the nearest half hour
  minimumTaskEstimate: 0.5       # no task gets less than half an hour
  ifParentHasNoEstimation: "skip" # Stories without points get no tasks

fibonacci-hours-table.atomize.yaml

Section titled “fibonacci-hours-table.atomize.yaml”

For teams whose hours grow faster than their points. A numeric conversion.table gives each Fibonacci value its own hours, so a 13-point Story is 80 hours rather than 13 × a fixed factor. A value that isn't in the table (often a typo, such as 4) is never guessed: with use-default it is treated as the default Story Estimate.

Key features shown:

  • conversion.table with numeric keys (1: 2, 2: 4, 3: 8, 5: 16, 8: 40, 13: 80)
  • ifParentHasNoEstimation: use-default with defaultParentEstimation: 5
  • A condition on estimation (gte 8): conditions compare the raw points, not the converted hours

Try it:

Terminal window
atomize validate examples/fibonacci-hours-table.atomize.yaml
atomize generate examples/fibonacci-hours-table.atomize.yaml --platform mock --story STORY-003 STORY-005
examples/fibonacci-hours-table.atomize.yaml
# Fibonacci story points that don't scale linearly to hours.
#
# A single factor treats every point as worth the same, but bigger stories
# usually carry more uncertainty and integration work. A numeric conversion
# table gives each point value its own hours. A value not in the table (e.g. a
# typo like 4) is not guessed: it falls back to the default Story Estimate.
#
#   13-point Story → 80 hours → Implement 55% = 44 h, ...
formatVersion: "1.0"
name: "Fibonacci Points to Hours"
description: "Maps Fibonacci story points to hours with a non-linear table, and adds an architecture review for large stories."
author: "Atomize"
tags: ["estimation", "table", "fibonacci"]


filter:
  workItemTypes: ["User Story"]
  excludeIfHasTasks: true


tasks:
  - id: "design"
    title: "Technical design"
    estimationPercent: 15
    activity: "Design"


  - id: "implement"
    title: "Implement: ${story.title}"
    estimationPercent: 55
    activity: "Development"
    dependsOn: ["design"]


  - id: "test"
    title: "Test: ${story.title}"
    estimationPercent: 25
    activity: "Testing"
    dependsOn: ["implement"]


  # Conditions on `estimation` compare the raw Story Estimate (the points),
  # not the converted hours.
  - id: "architecture-review"
    title: "Architecture review"
    estimationPercent: 5
    activity: "Design"
    dependsOn: ["design"]
    condition:
      field: "estimation"
      operator: "gte"
      value: 8


estimation:
  strategy: "percentage"
  conversion:
    table:
      1: 2
      2: 4
      3: 8
      5: 16
      8: 40
      13: 80
  rounding: "nearest"
  minimumTaskEstimate: 1
  ifParentHasNoEstimation: "use-default"  # unestimated or unlisted points...
  defaultParentEstimation: 5              # ...are treated as a 5-point Story (16 h)

STORY-003 (13 points) becomes 80 hours and gets the Architecture review; STORY-005 (3 points) becomes 8 hours without it.

tshirt-size-estimation.atomize.yaml

Section titled “tshirt-size-estimation.atomize.yaml”

Stories sized with T-shirt sizes in a custom picklist field. estimation.source names that field. When it is set, Atomize reads only that field, never falling back to story points. The table turns each size into hours, and multipliers: true also accepts fractional sizes, so 0.5XL is half the XL hours.

Key features shown:

  • estimation.source: Custom.TShirtSize (replace with your field's reference name)
  • A size table (XS: 2 … XL: 40) with multipliers: true
  • defaultParentEstimation: "M": unsized Stories are treated as M
  • Size conditions with equals (an Architecture review for L or XL Stories); use equals/not-equals for categories, never gt/lt
Story sizeConvertedBuild 60%Test 25%Review 10%Architecture review 5%
M8 h5 h2 h1 h:
L20 h12 h5 h2 h1 h
0.5XL20 h12.5 h5 h2 h:

When the Architecture review is skipped, its 5% is redistributed across the other tasks. Note that 0.5XL converts like half an XL, but it does not match the equals XL condition, because conditions compare the raw Story Estimate exactly.

Run Online Validation (--profile <name>) to check that the table covers every value of your picklist. It warns about sizes with no conversion and about table keys that aren't real picklist values.

Try it:

Terminal window
atomize validate examples/tshirt-size-estimation.atomize.yaml
atomize generate examples/tshirt-size-estimation.atomize.yaml --platform mock --story STORY-003
examples/tshirt-size-estimation.atomize.yaml
# T-shirt sized Stories, read from a custom picklist field.
#
# `source` names the Story field that holds the size. When it is set, Atomize
# reads only that field (no fallback to story points). The conversion table
# turns each size into hours; with `multipliers` a value like 0.3XL means
# 0.3 × the XL hours. Validate online (`--profile`) to check the table covers
# every value of the picklist.
#
#   L Story → 20 hours → Build 60% = 12 h, Test 25% = 5 h, ...
#   0.5XL Story → 0.5 × 40 = 20 hours
formatVersion: "1.0"
name: "T-shirt Size Estimation"
description: "Estimates tasks from a T-shirt size field (XS–XL), including fractional sizes such as 0.5XL."
author: "Atomize"
tags: ["estimation", "table", "t-shirt"]


filter:
  workItemTypes: ["User Story"]
  excludeIfHasTasks: true


tasks:
  - id: "build"
    title: "Build: ${story.title}"
    estimationPercent: 60
    activity: "Development"


  - id: "test"
    title: "Test: ${story.title}"
    estimationPercent: 25
    activity: "Testing"
    dependsOn: ["build"]


  - id: "review"
    title: "Code review"
    estimationPercent: 10
    activity: "Development"
    dependsOn: ["build"]


  # Sizes are categories, so compare them with equals (not gt/lt).
  - id: "architecture-review"
    title: "Architecture review"
    estimationPercent: 5
    activity: "Design"
    condition:
      any:
        - field: "estimation"
          operator: "equals"
          value: "L"
        - field: "estimation"
          operator: "equals"
          value: "XL"


estimation:
  strategy: "percentage"
  source: "Custom.TShirtSize"     # replace with your size field's reference name
  conversion:
    table:
      XS: 2
      S: 4
      M: 8
      L: 20
      XL: 40
    multipliers: true             # also accept 0.3XL, 0.5L, ...
  rounding: "nearest"
  minimumTaskEstimate: 0.5
  ifParentHasNoEstimation: "use-default"  # unsized Stories...
  defaultParentEstimation: "M"            # ...are treated as M (8 h)

The mock Stories have no T-shirt size field, so this dry run shows the fallback: each Story is treated as M (8 hours) and a warning explains why.

custom-fields-and-task-type.atomize.yaml

Section titled “custom-fields-and-task-type.atomize.yaml”

For a customised process that doesn't use the platform's standard estimation fields. The Story Estimate comes from a categorical Custom.Complexity field, tasks are created as a custom Deliverable work item type, and the effort is written to Custom.Effort instead of Remaining Work / Original Estimate.

Key features shown:

  • taskType: the child work item type (defaults to Task on Azure DevOps)
  • estimation.targetFields: replaces the platform's estimate fields entirely; values are written exactly as calculated (no unit) and Completed Work is not set
  • A categorical source with a table (Low: 4, Medium: 8, High: 16, Very High: 32)
  • ifParentHasNoEstimation: warn: an unknown complexity leaves the effort blank and reports a warning

Online Validation checks that Deliverable exists in the project and that Custom.Effort exists on it and is numeric.

Try it:

Terminal window
atomize validate examples/custom-fields-and-task-type.atomize.yaml
atomize generate examples/custom-fields-and-task-type.atomize.yaml --platform mock --story STORY-003 STORY-005
examples/custom-fields-and-task-type.atomize.yaml
# A customised process: categorical complexity field in, custom effort field out.
#
# - `source` reads the Story Estimate from a categorical field (Custom.Complexity).
# - `taskType` creates the child items as a custom work item type instead of
#   the platform default ("Task" on Azure DevOps).
# - `targetFields` writes the result to your own numeric field instead of
#   Remaining Work / Original Estimate. The number is written exactly as
#   calculated, and Completed Work is not set.
#
# Online validation (`--profile`) checks that the work item type exists and
# that the target fields exist on it and are numeric.
#
#   High Story → 16 hours → Analysis 20% = 3.2 h, Build 60% = 9.6 h, ...
formatVersion: "1.0"
name: "Complexity to Effort (Custom Process)"
description: "Reads a categorical complexity field and writes effort to a custom field on a custom child work item type."
author: "Atomize"
tags: ["estimation", "custom-process", "target-fields"]


filter:
  workItemTypes: ["User Story"]
  excludeIfHasTasks: true


taskType: "Deliverable"           # replace with your process's child work item type


tasks:
  - id: "analysis"
    title: "Analysis: ${story.title}"
    estimationPercent: 20


  - id: "build"
    title: "Build: ${story.title}"
    estimationPercent: 60
    dependsOn: ["analysis"]


  - id: "verify"
    title: "Verify: ${story.title}"
    estimationPercent: 20
    dependsOn: ["build"]


estimation:
  strategy: "percentage"
  source: "Custom.Complexity"
  conversion:
    table:
      Low: 4
      Medium: 8
      High: 16
      Very High: 32
  targetFields:
    - "Custom.Effort"             # replace with your numeric effort field
  rounding: "none"
  ifParentHasNoEstimation: "warn"  # unknown complexity → tasks with blank effort + a warning

STORY-003 (Very High) converts to 32 and STORY-005 (Medium) to 8.

repeated-review-tasks.atomize.yaml

Section titled “repeated-review-tasks.atomize.yaml”

One review conclusions Task per developer, written once. repeat: 4 creates four identical Tasks titled "Add review conclusions (1)" to "(4)". Each copy gets the full 10%, so the template sums to 10% + 50% + 4 × 10% = 100%.

Key features shown:

  • repeat on a task definition
  • validation.totalEstimationMustBe and maxTasks, which count each copy (6 Tasks are generated)
  • Ordinary dependsOn on the other tasks. A repeated task can't use dependsOn, and no task can depend on it
StoryDesign 10%Implement 50%Each review copy 10%
13 points1.36.51.3 (× 4)

Try it:

Terminal window
atomize validate examples/repeated-review-tasks.atomize.yaml
atomize generate examples/repeated-review-tasks.atomize.yaml --platform mock --story STORY-003
examples/repeated-review-tasks.atomize.yaml
# One review Task per developer, from a single task definition.
#
# `repeat: 4` creates four identical Tasks titled "Add review conclusions (1)"
# to "(4)". Each copy gets the full 10%, so the four copies together take 40%
# and the template still sums to 100%:
#
#   Design 10% + Implement 50% + 4 × Review 10% = 100%
#
# A repeated task can't use dependsOn, and no task can depend on it. Other
# tasks keep their dependencies as usual.
formatVersion: "1.0"
name: "Repeated Review Tasks"
description: "Implementation plus one review conclusions Task for each of the team's four developers."
author: "Atomize"
tags: ["review", "repeat"]


filter:
  workItemTypes: ["User Story"]
  excludeIfHasTasks: false


tasks:
  - id: "design"
    title: "Design: ${story.title}"
    estimationPercent: 10
    activity: "Design"


  - id: "implement"
    title: "Implement: ${story.title}"
    estimationPercent: 50
    activity: "Development"
    dependsOn: ["design"]


  - title: "Add review conclusions"
    description: "Review the change and record your conclusions."
    estimationPercent: 10
    repeat: 4                    # one copy per developer; at most 20 unless validation.maxRepeat is raised
    activity: "Development"
    assignTo: "@Unassigned"


estimation:
  strategy: "percentage"


validation:
  totalEstimationMustBe: 100     # counts each copy: 10 + 50 + 4 × 10
  maxTasks: 8                    # counts each copy: 6 Tasks are generated

Running All Examples

Section titled “Running All Examples”
Terminal window
# Validate all examples
for f in examples/*.yaml; do
  echo "Validating $f..."
  atomize validate "$f"
done


# Dry-run examples that match the bundled mock filters
for f in examples/backend.atomize.yaml examples/frontend.yaml examples/conditional-percentage-template.atomize.yaml; do
  echo "Testing $f..."
  atomize generate "$f" --platform mock
done


# Dry-run examples whose filters are intentionally more specific than the mock dataset
atomize generate examples/fullstack.atomize.yaml --platform mock --story STORY-004
atomize generate examples/conditional-dependencies-template.atomize.yaml --platform mock --story STORY-004
atomize generate examples/advanced-filtering.atomize.yaml --platform mock --story STORY-001
Section titled “Related”

Each example uses fields described in the Schema Reference and explained in the Template guides, from filters to estimation. See the complete example for one Template that combines them.