| name | add-feature |
| description | Add new functionality by understanding existing patterns and dependencies before writing code. Locates where the feature belongs, studies conventions, implements following precedent, then verifies integration. Use when asked to add a feature, flag, endpoint, component, or module. |
| compatibility | Requires tokenlean CLI tools (npm i -g tokenlean) and git |
Add Feature
Add functionality by understanding existing code before writing new code.
Workflow
Locate โ Understand โ Implement โ Integrate โ Verify
1. Locate
Find where the feature belongs:
tl parallel "tl structure" "tl entry" "tl example <pattern>"
2. Understand
Before writing a single line:
tl parallel \
"symbols=tl symbols <file>" \
"style=tl style" \
"deps=tl deps <file>" \
"exports=tl exports <file>"
3. Implement
tl snippet <function> <file>
tl npm <package>
4. Integrate
Wire it into the existing system:
tl parallel \
"impact=tl impact <modified-file>" \
"guard=tl guard" \
"diff=tl diff --breaking"
5. Verify
tl parallel "test=tl run '<test command>'" "testmap=tl test-map <file>"
Decision tree
Feature request โ Does similar functionality exist?
โโ Yes (extending) โ tl example to find the pattern
โ โ tl symbols on target file
โ โ tl snippet on the function to extend
โ โ Implement following the existing pattern
โโ Yes (replacing) โ tl impact on what you're replacing
โ โ tl exports to check public API surface
โ โ Implement, update all consumers
โโ No (greenfield) โ tl structure for placement
โ tl style for conventions
โ tl entry to understand how it'll be wired in
โ Implement, then tl guard to check integration
Tips
- Always run
tl example before implementing โ the codebase almost always has a precedent
- Use
tl npm before adding any new dependency โ check size and health
- Run
tl diff --breaking after modifying any file with exports
- For React/frontend projects, also use
tl component on main UI files
- If a file is under 150 lines, just read it directly โ tokenlean overhead isn't worth it