tspec doesn't replace Jira. It syncs with Jira. Bidirectionally.

Every enterprise already has a project management tool. Often several. The PM lives in Jira. The developer lives in the IDE. The QA engineer lives in the test runner. The CTO lives in the dashboard. tspec does not ask anyone to change where they live. It connects those worlds through bidirectional integrations that keep typed specifications in sync with whatever the organization already uses.

Jira Bidirectional Sync📋

This is the integration that sells tspec to enterprise teams. It works in both directions.

Direction 1: Jira to tspec — tspec sync --source=jira reads the Jira API and generates feature classes in the target language. A Jira Epic becomes a tspec Epic. A Jira Story becomes a tspec Feature. Sub-tasks become acceptance criteria. The generated code lands in your repository, ready to be committed:

tspec sync --source=jira \
  --project=PAY \
  --output=src/specs/jira-imported/ \
  --language=typescript

This creates typed feature files from every ticket in the PAY project. Developers fill in the AC validation logic. The structure comes from Jira; the type safety comes from tspec.

Direction 2: tspec to Jira — tspec push updates Jira custom fields with coverage data from the latest scan. Every Jira ticket linked to a tspec feature gets two custom fields:

• tspec_coverage — percentage of ACs with passing tests (e.g., 85%)
• tspec_status — the tspec workflow state (e.g., InProgress, Review, Done)

PMs see coverage data without ever leaving Jira. No tab switching. No second dashboard.

Direction 3: Jira webhooks — When a ticket changes in Jira (new AC added, story re-prioritized, epic restructured), a webhook triggers a re-sync. The tspec feature files in the repository are updated via a pull request, so developers review the structural change through normal code review.

The mapping between Jira and tspec concepts is explicit:

Azure DevOps Sync📋

Azure DevOps integration follows the same bidirectional pattern as Jira:

• Work Items to features — Epics, Features, User Stories, and Tasks map to tspec's hierarchy. PBIs (Product Backlog Items) become Features with ACs extracted from the acceptance criteria field.
• Test Plans to coverage — Azure Test Plans results feed into tspec coverage. When a test case linked to a work item passes, the corresponding AC is marked covered.
• Boards updates — tspec pushes coverage percentages back to work item custom fields, visible on Azure Boards cards.

Configuration uses Azure DevOps personal access tokens or service principals:

tspec sync --source=azdo \
  --organization=acme \
  --project=PaymentsPlatform \
  --output=src/specs/

Linear Sync📋

Linear's API is cleaner than Jira's, which makes the integration simpler:

• Issues to features — Linear issues map to tspec Features. Labels map to tags. Priority maps to the support-level severity field.
• Projects to Epics — Linear projects become tspec Epics, with child issues becoming child Features.
• Cycles — Linear cycle boundaries are used to scope trend reports: "coverage at the start of cycle 12 vs. end of cycle 12."

Linear's webhook system triggers re-syncs on issue changes, just like the Jira integration.

Slack Notifications📋

Slack integration is outbound-only — tspec pushes notifications to configured channels. Four categories of alerts are configurable per project:

Workflow transitions — "Feature NAV-001 moved from InProgress to Review by s.erard@acme.com." Useful for PMs who track progress without opening the dashboard.

Coverage drops — "Feature PAY-042 coverage dropped from 100% to 80%. 2 ACs lost coverage after commit abc1234." This catches regressions the moment they happen.

Quality gate failures — "Build failed: 3 features below 90% coverage threshold. See dashboard for details." Sent to the team channel so everyone knows the build is blocked.

SLA warnings — "Support ticket SUPPORT-789 (P1) has 2 hours remaining before SLA breach." For the support workflow from Part IX.

Each notification includes a deep link to the relevant dashboard page. Slack threads are used for follow-up — replying to a coverage drop notification with tspec status PAY-042 (via a Slack bot) returns the current coverage inline.

CI/CD Integration📋

tspec fits into every major CI/CD platform. The tspec ci command runs a scan, checks quality gates, and exits with code 0 (pass) or 1 (fail). That is all a CI pipeline needs.

The GitHub Actions integration is the most polished. It posts a PR comment with a coverage summary table:

- name: tspec coverage check
  uses: tspec/ci-action@v1
  with:
    threshold: 90
    push: true
    comment: true

This runs the scan, fails the check if any feature is below 90% coverage, pushes results to Diem, and posts a Markdown comment on the pull request showing which features gained or lost coverage in this PR.

For GitLab and Azure Pipelines, the same behavior is achieved with tspec ci --strict --push --format=markdown > coverage-report.md and platform-specific comment posting.

OpenAPI Bridge📋

REST APIs have a natural specification: the OpenAPI document. tspec's OpenAPI bridge imports an OpenAPI spec and creates one AC per endpoint:

tspec openapi import --spec=openapi.yaml --output=src/specs/api/

Each endpoint becomes an AC with:

• The HTTP method and path as the AC description
• The request schema as expected input
• The response schema as expected output
• Status codes as validation criteria

When contract tests (Pact, Dredd, Schemathesis) run against these endpoints, their results feed into tspec coverage. The combination of typed behavioral specs and OpenAPI shape specs gives complete coverage: "the feature does the right thing" (tspec) AND "the API returns the right shape" (OpenAPI).

Grafana and Datadog: Coverage as Metrics📋

tspec exports coverage data as Prometheus-compatible metrics. This means existing observability stacks — Grafana, Datadog, New Relic — can display coverage trends alongside uptime, latency, and error rates.

Three metrics are exposed:

tspec_coverage_percentage{project="payments",feature="NAV"} 0.95
tspec_acs_total{project="payments"} 142
tspec_acs_covered{project="payments"} 135

• tspec_coverage_percentage — gauge, per-feature or per-project coverage
• tspec_acs_total — counter, total acceptance criteria in scope
• tspec_acs_covered — counter, acceptance criteria with passing tests

A Grafana dashboard with these three metrics gives engineering leadership a real-time view of specification health alongside operational health. When coverage drops correlate with incident spikes, the connection between "we stopped testing" and "things broke" becomes visible.

The metrics endpoint is available on the Diem API at /metrics and follows the OpenMetrics standard, so scraping works with any Prometheus-compatible collector.

The Integration Landscape📋

All integrations flow through the Diem API. The CLI is the entry point for scans; the API is the hub for everything else:

The pattern is consistent: external systems either push data into tspec (OpenAPI import, Jira sync) or pull data from tspec (Slack notifications, Grafana metrics), or both (Jira bidirectional, Azure DevOps bidirectional). The Diem API is the single integration point. No point-to-point spaghetti.

What Comes Next📋

Enterprise features and integrations make tspec deployable. But when does each piece ship? What does it cost? And what does the full picture look like for a CAC40 company evaluating tspec today? Part XIII covers the roadmap and go-to-market strategy.

Previous: Part XI — Enterprise Features | Next: Part XIII — Roadmap and Go-to-Market