Cursor Product Context

Cursor is powerful when it understands the codebase. It still needs product context: why a feature exists, what trade-offs were made, and which constraints cannot be broken.

Notiky composes that context from decisions, artifacts, and ship plans so Cursor work starts closer to product intent.

Cursor can inspect the files in a repository, while Notiky holds the product reasoning shared across projects and people. Use the connection to bring relevant decisions and task context into the editor before asking for an implementation. Repository instructions still define the local architecture and verification commands.

Start with a Notiky workspace and a project that contains the work you want to build. Use the connection guidance in Notiky Settings to configure the supported MCP connection in Cursor. Confirm the selected workspace and project before asking the agent to retrieve product knowledge.

Choose a bounded task and ask Cursor to summarize its goal, constraints, and acceptance criteria from Notiky. Read the summary before it edits code. If the task depends on an unresolved product assumption, clarify that assumption in the shared plan so the next session receives the same answer.

For an onboarding change, the context could explain the intended first action, the evidence behind it, and the account rules that must remain intact. Cursor can use that brief while examining components, making changes, and running the repository checks.

Ask for the files changed, checks performed, and remaining limitations. Review the implementation against the original task before accepting it. Record a durable product lesson when the work teaches the team something new; keep routine code details in version control. The next agent should find the current decision and its rationale without replaying the whole session.