Feature Document

I use the below instructions in my AGENTS.md, CLAUDE.md etc. instructions in my user directory so that I can seamlessly use the Feature Document format in all my projects.

# Feature Document Format

This document format is to be used for creating, maintaining
and documenting software modules, features or components, if the user requests it.
If requested, following this guide is mandatory and all
Feature Documents must have the requirements and technical details in a document like this.
Progress of the implementation must be tracked in the Feature Document.
The document must be kept up-to-date with the final technical details.

Dos:
- **Important:** Keep other existing documents that are impacted by the new
  feature or module up-to-date. This should be reflected in the Action Plan section.
- Place Feature Documents into the appropriate document subdirectory:
  for example backend specific ones into `backend`, frontend specific ones
  into `frontend` etc. Cross-cutting features go into `features`.
- Keep the Feature Document evergreen: once the feature or update is delivered,
  the technical section should have only the latest information.

Don'ts:
- Do not keep a history or legacy sections in finalised documents.
  Only keep the "current state" while the new features are being delivered
  and remove them once done.
- Do not duplicate documentation: keep technical details in one place,
  an authoritative document

Sample:

\```
# Fantastic New Feature

Status: <To Be Reviewed|Requirement|In Progress|Developed|Updated Requirement>

## Objectives

- What the feature wants to achieve: user outcomes


## Action Plan [required except for `Developed`]

- Detailed specific action items to achieve the outstanding objectives
- Must be kept up to date ticking off objectives
- Must be removed once ALL outstanding objectives are achieved

## Technical Details

- Deep technical details on implementation
- This should be detailed enough to make the delivery completely clear
  or the achieved code changes fully documented
- Include code snippets, API/internal contracts, security considerations etc.
- Comprehensive testing scope required

### Subsection

- For complex features and modules, can have subsections

**IMPORTANT:** When `Updated Requirement`, a new subsection or subsections
are mandatory to show what is changing. 
he original technical content must not be removed until the update is complete.
When the update is complete, the technical details must be harmonised
with the new codebase and old references removed.
There must never be "this was like this, now it is like that",
the `Developed` document must always reflect the final,
current codebase only. History is for git.

\```

## Document lifecycle

1. Newly created Feature Document: `To Be Reviewed`
2. New technical requirements reviewed by user: `Requirement`
3. While being developed: `In Progress`
4. Completed development: `Developed`
5. Technical content to be updated: `Updated Requirement`
6. While the update being updated: go to #2.

### Finishing

Once the document is completed and marked `Developed`, scan the language
to remove any change log style statements like "now the source is...",
"in this version..." etc.
The document is evergreen, reflects the current state of the codebase only.

Feature Documents that are `To Be Reviewed` must NOT be implemented
or progressed until the user gives explicit instruction.