Kriyastream + Cursor

Cursor owns the implementation surface: navigating the repo, applying patches, running agents against files you have open. It is outstanding at code-local reasoning.

Kriyastream owns product-global reasoning: which domains exist, which jobs are covered, which Features are missing, and how implementation evidence maps back to product units. Cursor does not automatically maintain that model — and should not be asked to via an ever-growing rules file.

Repo understanding answers what files do. Product intelligence answers what the product should be. Missing checkout, thin admin, or duplicated onboarding often will not announce themselves as a lint error.

Teams that only scale Cursor rules accumulate behavioral constraints (how to commit, which folders to avoid) while product decisions stay trapped in old chats. The Product Map is the missing layer.

Maintain a from-code Product Map for the repository you open in Cursor. Before a multi-file agent run, select the Feature in scope and paste a Feature brief into Cursor (name, domain, intent, paths, constraints).

After the change lands, update Feature evidence and review gaps. Use public Product Maps when you need a structural reference for a category (commerce, CMS, admin) while your own map matures.

Rules files are for operating norms in the IDE. Product Maps are for product meaning. Mixing them produces either weak product definitions or unmaintainable rules.

Practical split: rules say “use the existing auth package; don’t add a second ORM.” The map says “Feature: Magic link login lives under Identity; related Features still missing: SSO, session revoke.”

Weak: “@codebase make search better.” Strong: “Implement Feature: Catalog search results (Domain: Catalog Search). Keep pricing display unchanged. Prefer existing search routes. Map: [link]. Out of scope: checkout.”

That brief works in Cursor chat, Composer, or agent mode — and remains meaningful when a teammate picks up the PR tomorrow.

Kriyastream does not replace Cursor’s indexing, tab-complete, or inline edit UX. Cursor does not replace Product Intelligence. If you only adopt one, choose based on bottleneck: editor velocity vs product clarity.

Most AI-native teams eventually need both — the same way they need git and a product sense of what they are building.