Kriyastream

Guide

How do I connect a PR to a product requirement?

A pull request should change a known product unit — usually a Feature under a Capability — not an orphan branch of code. “Connected to a requirement” means the PR is traceable to Product Map structure, with ticket keys as optional workflow glue.

Get started with Kriyastream

Why ticket-only linking fails

Most teams paste `PROJ-123` into a PR title and call it provenance. That works for sprint reporting. It fails as product truth: tickets get renamed, closed, split, or deleted; epics end when projects end; AI agents generate tickets faster than humans can curate meaning.

When the only link is an issue ID, you cannot answer: which user job did this PR advance? which capability is now more complete? which adjacent features are still missing? Product requirements need a stable identity outside the issue tracker.

  • Issue IDs are workflow references, not product structure
  • Closed tickets lose discoverability for future agents
  • AI-generated backlogs amplify orphan PRs

The chain that actually holds: requirement → Feature → code → PR

In Kriyastream, a product requirement for implementation grain is typically a Feature on the Product Map (under Capability → Experience → JTBD → Domain). That Feature is the durable requirement identity.

Code Intelligence associates path patterns and repo evidence with Features when available. A PR then proves a change against that Feature — and optionally cites a Linear/Jira issue for ownership and status.

  • Feature = product requirement (what/why)
  • Paths / repo evidence = where it lives
  • PR = proof of change
  • Issue key = who/when/status (optional)

What to put in the PR description

Make the Feature explicit in human-readable language agents and reviewers can reuse. Prefer: Feature name, Domain, short intent, and links to the map (and issue if used). Avoid only cryptic keys.

Example pattern: “Delivers Feature: Checkout — apply discount codes (Domain: Storefront Shopping). Map: [link]. Issue: LIN-482 (execution only).” Reviewers and future Claude Code / Cursor sessions then know the product unit, not just the ticket.

After merge: keep provenance alive

Closing a PR is not the end of the link. Confirm the Feature’s code evidence still matches reality. If the PR introduced new paths, update path patterns. If the Feature is complete enough to score differently, revisit gaps.

That is how product provenance compounds: each merge strengthens the map agents will read next week — instead of dumping knowledge back into chat history.

Using Linear or Jira without losing the product layer

Keep Linear/Jira for cycles, assignees, and SLAs. Do not let the issue become the only definition of the requirement. Create or select the Feature first, then open the issue from that Feature’s intent.

See the vs Linear and vs Jira pages for when both tools belong in the stack.

How to do it

  1. 1On the Product Map, identify (or create) the Feature the change should deliver.
  2. 2Optionally create a Linear/Jira issue linked to that Feature for assignment and status.
  3. 3Implement in the repo paths associated with the Feature when known; note new paths if you invent them.
  4. 4Open the PR with Feature name + Domain + map link (and issue key if used).
  5. 5On merge, update Feature code evidence and re-check related gaps or score.

FAQ

Do I still use Linear or Jira?

Yes if your team needs issue workflow. Kriyastream owns product requirement identity; the tracker owns execution status. Linking both is normal — linking only the tracker is the anti-pattern.

What if the PR spans multiple Features?

Split when you can. If you cannot, list the primary Feature and secondary Features explicitly, and avoid burying multiple intents under one ticket title.

What counts as a “requirement” on the Product Map?

For shipping code, Feature is the usual grain. Larger requirement themes often sit at Capability or JTBD level, then decompose into Features before PRs.

How does this help coding agents?

Agents starting from a Feature inherit durable product language and scope. Agents starting from a closed ticket ID inherit almost nothing durable.