leetkick/design_docs/TEMPLATE.md

A CLI tool for scaffolding LeetCode exercises with language-specific testing setups

# Project/Feature Name {#project-feature-name}

**Link:** [design-doc](link)  
**Author(s):** [Author Name](mailto:author@example.com)  
**Status:** Draft/In Progress/Completed  
**Last Updated:** [MMM dd, yyyy]

## Table of Contents

1. [Summary](#summary)
2. [Context](#context)
3. [Detailed Design](#detailed-design)
   - [Proposed Solution 1](#proposed-solution-1)
   - [Proposed Solution 2](#proposed-solution-2)
   - [Proposed Solution 3](#proposed-solution-3)
4. [Testing and Validation](#testing-and-validation)
5. [Future Considerations](#future-considerations)

---

## Summary {#summary}

This is a TLDR of the document.

## Context {#context}

Describe the background and reasoning behind this project. Include any relevant history, prior work, or motivating factors.

## Detailed Design {#detailed-design}

Include diagrams or pseudo-code if necessary.
If actual code helps to understand the solution, include it.

### Proposed Solution 1

Provide a high-level diagram or explanation of the solution.

| Pros          | Cons          |
| ------------- | ------------- |
| This is a pro | This is a con |

### Proposed Solution 2

Provide a high-level diagram or explanation of the solution.

| Pros          | Cons          |
| ------------- | ------------- |
| This is a pro | This is a con |

### Proposed Solution 3

Provide a high-level diagram or explanation of the solution.

| Pros          | Cons          |
| ------------- | ------------- |
| This is a pro | This is a con |

---

## Testing and Validation {#testing-and-validation}

Explain how the solution will be tested.
Don't write about the testing itself, but about the testing process.

- Unit tests
- Edge cases
- Metrics

---

## Future Considerations {#future-considerations}

- Things that were excluded
- Things that were considered but not implemented
- Trade-offs

---