FDD Cursor Rules
below 4 core action-rules for cursor to make FDD flow smoothly
below 4 core action-rules for cursor to make FDD flow smoothly
After observing our development flow and documentation challenges, we're implementing key architectural improvements to make Mercury's development more maintainable and clear. This post documents these decisions for future reference.
During a recent code review of our shadow portfolio feature, we discovered a concerning pattern where FDD documentation was artificially inflated by duplicating TypeScript type definitions. This experience provides valuable lessons about what makes FDD documentation effective - and what doesn't.
original discussion: https://chatgpt.com/canvas/shared/680a63d740208191bf079900ab70daf3
code → FDDRule Name: postfactum-fdd-for-implementation
Trigger: When a module or feature is already implemented and a Feature-Driven Document (FDD) needs to be created.
Action: Generate an FDD that serves as a compressed context snapshot. Avoid architectural evangelism or commentary. This FDD is not for onboarding, it’s a memory prosthetic for the author.