Feature specifications
One level deeper than the PRD — what each feature does, in enough detail to build it.
A PRD tells you what the product is. A feature specification tells you how a single feature behaves: the flows, the states, the edge cases and the decisions that would otherwise be rediscovered mid-implementation.
Ideon writes these against the feature tree it already produced, so the specs stay consistent with the mindmap and with each other. That consistency is the point — it is where hand-written documentation usually falls apart.
Feature specs are the most detailed document Ideon produces, which is why they cost the most credits to generate.
From features to behaviour
The mindmap tells you a feature exists. A specification tells you what it does when someone uses it: the states it can be in, the flow through it, and the edge cases that would otherwise be discovered during implementation. That is the level of detail this document works at.
Consistency is the hard part
Hand-written specs drift. One references a field another feature deleted last month. Because Ideon writes every spec against the same feature tree and the same questionnaire answers, the boundaries between features stay aligned by construction.
The most detailed output
Feature specs cost the most credits because they are the most detailed document Ideon produces — one section per feature, each expanding behaviour rather than restating intent.
What you get
One spec per feature
Each top-level feature gets its own section, so a spec can be read in isolation.
Behaviour, not just intent
Describes flows, states and edge cases rather than restating the feature name.
Consistent with the mindmap
Generated from the same structure, so node names and boundaries line up.
Ready for implementation
Detailed enough that an engineer — or an agent — can start without a follow-up meeting.
How it works
- 1
Finish the questionnaire and mindmap
Specs are generated from the validated feature tree.
- 2
Generate the specs
Ideon expands each feature into behaviour, states and edge cases.
- 3
Refine and regenerate
Tighten the answers that feed a specific feature, then regenerate as the design settles.
Good for
- Handing a well-defined feature to a developer
- Reducing back-and-forth during implementation
- Keeping parallel workstreams aligned