Skip to content

Commit 9f76336

Browse files
IamAshrafeeIamAshrafee
committed
Add /invent-features workflow and comprehensive workflows README
- /invent-features: Discover missing features through gap analysis, competitor mining, user type analysis, and 10x thinking. Evaluate against project principles. - .agent/workflows/README.md: Master reference for all 17 workflows with: Quick reference table, 'When to Use What' decision guide, category explanations, common chains, and workflow rules.
1 parent 5073ccb commit 9f76336

2 files changed

Lines changed: 327 additions & 0 deletions

File tree

‎.agent/workflows/README.md‎

Lines changed: 228 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,228 @@
1+
# ModularAuth-Kit — Workflow Reference
2+
3+
> Workflows are slash commands that guide the AI agent through structured, repeatable processes. Each workflow adopts a specific mindset and follows a defined checklist.
4+
5+
---
6+
7+
## Quick Reference
8+
9+
| Command | Category | One-Line Summary |
10+
|---|---|---|
11+
| `/develop` | Build | Follow the roadmap to implement the next phase |
12+
| `/add-feature` | Build | Plan, implement, test, and document a new feature |
13+
| `/refine-feature` | Build | Improve an existing feature without breaking changes |
14+
| `/update-docs` | Maintain | Sync all docs after a feature change |
15+
| `/update-website` | Maintain | Sync website pages after docs change |
16+
| `/prepare-release` | Release | Verify, build zip, changelog, tag, push |
17+
| `/verify-docs` | Audit | Check all docs accuracy against source code |
18+
| `/security-audit` | Audit | OWASP Top 10, password, sessions, tokens, CSRF |
19+
| `/code-quality-audit` | Audit | TypeScript strictness, patterns, naming, dead code |
20+
| `/dependency-audit` | Audit | Vulnerabilities, outdated, unused deps, licenses |
21+
| `/performance-audit` | Audit | Queries, indexes, memory, hashing, async patterns |
22+
| `/search-potential-bugs-for-future` | Audit | Scan codebase for potential bugs |
23+
| `/dx-review` | Think | Think like a new developer — find setup friction |
24+
| `/project-health-check` | Think | Think like a PM — health, risks, priorities |
25+
| `/architecture-review` | Think | Think like a senior reviewer — structure, smells |
26+
| `/brainstorm` | Think | Creative session — wild ideas, filter, rank |
27+
| `/red-team` | Think | Think like an attacker — break the auth system |
28+
| `/user-review` | Think | Think like a user — README, website, trust |
29+
| `/invent-features` | Think | Discover missing features, evaluate, propose |
30+
31+
---
32+
33+
## When to Use What
34+
35+
### "I just added or changed a feature"
36+
37+
```
38+
/update-docs → /update-website → /verify-docs
39+
```
40+
41+
This is the most common sequence. After any code change that affects behavior, config, endpoints, or error codes, run these three in order. They ensure everything from the FAQ to the website stays in sync with the source code.
42+
43+
---
44+
45+
### "I want to add a new feature"
46+
47+
```
48+
/add-feature → /update-docs → /update-website → /verify-docs
49+
```
50+
51+
`/add-feature` walks through the full lifecycle: planning, config, implementation (model → repo → service → validation → controller → route), testing, and documentation. Then the maintenance workflows sync everything.
52+
53+
---
54+
55+
### "I want to improve something that already exists"
56+
57+
```
58+
/refine-feature → /update-docs → /update-website
59+
```
60+
61+
`/refine-feature` emphasizes backwards compatibility — no breaking changes, no removed config options, no changed response shapes. It checks edge cases and makes sure old consumers aren't affected.
62+
63+
---
64+
65+
### "I want to ship a new release"
66+
67+
```
68+
/security-audit → /code-quality-audit → /dependency-audit → /verify-docs → /prepare-release
69+
```
70+
71+
Before any release, run the full audit suite. Fix everything found, then `/prepare-release` handles the final verification, changelog, and tagging.
72+
73+
---
74+
75+
### "I want to find problems before they find me"
76+
77+
Pick one or more:
78+
79+
| Worried about... | Run |
80+
|---|---|
81+
| Security vulnerabilities | `/security-audit` + `/red-team` |
82+
| Code quality and tech debt | `/code-quality-audit` + `/architecture-review` |
83+
| Slow performance at scale | `/performance-audit` |
84+
| Outdated or risky dependencies | `/dependency-audit` |
85+
| Documentation lies | `/verify-docs` |
86+
| Hidden bugs | `/search-potential-bugs-for-future` |
87+
88+
---
89+
90+
### "I want to make the project better but don't know where to start"
91+
92+
```
93+
/project-health-check → then pick what it recommends
94+
```
95+
96+
This gives you an overall health score and identifies the top 3 priorities. Follow its advice.
97+
98+
Or, for specific perspectives:
99+
100+
| Question | Run |
101+
|---|---|
102+
| "Is this easy to use?" | `/dx-review` |
103+
| "Would users like this?" | `/user-review` |
104+
| "Is the code well-structured?" | `/architecture-review` |
105+
| "What features are we missing?" | `/invent-features` |
106+
| "What wild ideas could help?" | `/brainstorm` |
107+
| "Can someone hack this?" | `/red-team` |
108+
109+
---
110+
111+
### "I want to figure out what to build next"
112+
113+
```
114+
/invent-features → /brainstorm → /project-health-check
115+
```
116+
117+
Start with `/invent-features` to systematically discover gaps. Use `/brainstorm` for creative 10x ideas. Then `/project-health-check` to prioritize against project goals. The best ideas go into `dev-docs/future-thinking.md`.
118+
119+
---
120+
121+
### "I just want to follow the roadmap"
122+
123+
```
124+
/develop
125+
```
126+
127+
This reads `dev-docs/ROADMAP.md`, finds the next incomplete phase, and implements it following all conventions and patterns.
128+
129+
---
130+
131+
## Workflow Categories Explained
132+
133+
### 🔨 Build Workflows
134+
135+
These workflows **create things** — new features, improvements, or roadmap phases.
136+
137+
| Workflow | When | Why |
138+
|---|---|---|
139+
| `/develop` | Starting a dev session | Follows the roadmap sequentially, implements the next phase |
140+
| `/add-feature` | Feature doesn't exist yet | Full lifecycle from planning to documentation |
141+
| `/refine-feature` | Feature exists but needs improvement | Ensures backwards compatibility while improving behavior |
142+
143+
### 🔧 Maintain Workflows
144+
145+
These workflows **keep things in sync** — they don't change behavior, just documentation and presentation.
146+
147+
| Workflow | When | Why |
148+
|---|---|---|
149+
| `/update-docs` | After any code/feature change | Docs, FAQ, AI prompt, use-cases all reference the code — they must stay accurate |
150+
| `/update-website` | After docs change | The website mirrors docs — feature grid, endpoint tables, code examples |
151+
| `/prepare-release` | Ready to ship a version | Ensures release zip is clean, changelog is written, tag is created |
152+
153+
**Key rule:** Always run `/update-docs` before `/update-website`. Docs are the source of truth for the website.
154+
155+
### 🔍 Audit Workflows
156+
157+
These workflows **find problems** — they check the code against standards and best practices.
158+
159+
| Workflow | What It Checks | Run Frequency |
160+
|---|---|---|
161+
| `/security-audit` | OWASP Top 10, passwords, sessions, tokens, CSRF, rate limits | Before every release |
162+
| `/code-quality-audit` | TypeScript strictness, error handling, naming, dead code, duplication | Monthly or before release |
163+
| `/dependency-audit` | npm vulnerabilities, outdated packages, unused deps, licenses | Monthly |
164+
| `/performance-audit` | Database queries, indexes, middleware overhead, memory, async patterns | Before scaling or on slow reports |
165+
| `/verify-docs` | Every number, default, code example against actual source code | Before every release |
166+
| `/search-potential-bugs-for-future` | Code patterns that could cause bugs under edge conditions | When bored or suspicious |
167+
168+
### 🧠 Think Workflows
169+
170+
These workflows **change your perspective** — they force the AI to think from a specific viewpoint to find things a generic review would miss.
171+
172+
| Workflow | Mindset | Best For |
173+
|---|---|---|
174+
| `/dx-review` | 🧑‍💻 A developer using this for the first time | Finding setup friction, confusing docs, missing context |
175+
| `/project-health-check` | 📋 A project manager prioritizing work | Finding gaps in the user journey, risk assessment, sprint planning |
176+
| `/architecture-review` | 👨‍🏫 A senior engineer doing code review | Finding layering violations, coupling, code smells, inconsistencies |
177+
| `/brainstorm` | 💡 A creative thinker without constraints | Generating wild ideas, then filtering for feasibility |
178+
| `/red-team` | 🏴‍☠️ An attacker trying to break in | Finding exploitable vulnerabilities in auth flows |
179+
| `/user-review` | 👤 A user deciding whether to adopt | Evaluating first impressions, README clarity, trust signals |
180+
| `/invent-features` | 🔬 A product person finding gaps | Discovering missing features through user analysis and competitor comparison |
181+
182+
---
183+
184+
## Common Chains
185+
186+
### After a Change
187+
```
188+
[make code changes] → /update-docs → /update-website → /verify-docs
189+
```
190+
191+
### Full Feature Development
192+
```
193+
/invent-features → /add-feature → /update-docs → /update-website → /verify-docs
194+
```
195+
196+
### Pre-Release Audit
197+
```
198+
/security-audit → /code-quality-audit → /dependency-audit → /performance-audit → /verify-docs → /prepare-release
199+
```
200+
201+
### Deep Quality Review
202+
```
203+
/architecture-review → /code-quality-audit → /red-team → /performance-audit
204+
```
205+
206+
### Strategic Planning Session
207+
```
208+
/project-health-check → /invent-features → /brainstorm → /dx-review → /user-review
209+
```
210+
211+
### Monthly Maintenance
212+
```
213+
/dependency-audit → /verify-docs → /search-potential-bugs-for-future
214+
```
215+
216+
---
217+
218+
## Rules
219+
220+
1. **All workflows use `// turbo-all`** — Commands auto-run without asking for approval each time.
221+
2. **Build workflows commit their work** — Each ends with a commit step.
222+
3. **Audit workflows fix what they find** — Don't just report; fix and commit.
223+
4. **Think workflows produce reports** — They output findings, not code changes (unless quick wins are found).
224+
5. **Maintain workflows are idempotent** — Running them twice produces the same result.
225+
226+
---
227+
228+
*17 workflows · Created for ModularAuth-Kit · [Ashrafee](https://github.com/IamAshrafee)*

‎.agent/workflows/invent-features.md‎

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
description: Brainstorm and evaluate potential new features — think about what's missing, what users would pay for, and what would differentiate the project
3+
---
4+
5+
# Invent New Features
6+
7+
Systematically discover features that should exist but don't yet.
8+
9+
## 1. Listen to the Gaps
10+
11+
Read through existing documentation and find implicit promises that aren't fulfilled:
12+
13+
```bash
14+
# Find "coming soon", "future", "TODO", "planned" mentions
15+
grep -rni "coming soon\|future\|TODO\|planned\|not yet\|will be" docs/ README.md dev-docs/
16+
```
17+
18+
Read `docs/FAQ.md` — every question that starts with "Can I..." or "Does it support..." is a feature request signal.
19+
20+
Read `dev-docs/future-thinking.md` — what's listed but not started?
21+
22+
## 2. Gap Analysis by User Type
23+
24+
Think about who uses this project and what they need that we don't have:
25+
26+
### Solo Developer (side project)
27+
- What's the minimum auth they need?
28+
- What would save them the most time?
29+
- What security features would they skip if they could? (And shouldn't)
30+
31+
### Startup Team (MVP → production)
32+
- What features do they need at launch vs post-launch?
33+
- What would make them choose this over Auth0/Firebase?
34+
- What compliance features do they need? (GDPR, SOC2)
35+
36+
### Enterprise / Agency
37+
- What would stop them from adopting this?
38+
- What customization do they expect?
39+
- What audit/logging features are table stakes?
40+
41+
## 3. Feature Mining from Competitors
42+
43+
Without leaving the codebase, think about what these tools offer that we don't:
44+
45+
| Feature | Passport.js | Auth0 | Firebase Auth | NextAuth | Us? |
46+
|---|---|---|---|---|---|
47+
| Magic links | ❌ | ✅ | ✅ | ✅ | ❌ |
48+
| Passwordless | ❌ | ✅ | ✅ | ❌ | ❌ |
49+
| MFA/TOTP | ❌ | ✅ | ✅ | ❌ | ❌ |
50+
| RBAC | ❌ | ✅ | ✅ | ❌ | ❌ |
51+
| Webhooks | ❌ | ✅ | ✅ | ❌ | ❌ |
52+
| Admin API | ❌ | ✅ | ✅ | ❌ | ❌ |
53+
| Rate limiting | ❌ | ✅ | ✅ | ❌ | ✅ |
54+
| Account linking | ❌ | ✅ | ✅ | ✅ | ✅ |
55+
56+
Which missing features would have the highest impact?
57+
58+
## 4. "10x" Feature Ideas
59+
60+
Think beyond incremental improvements. What feature would make someone tweet about this project?
61+
62+
- **Zero-config magic** — Detect the user's project structure and auto-configure everything
63+
- **Auth health dashboard** — CLI command that shows auth security score, active sessions, failed logins
64+
- **One-click compliance** — Generate GDPR data export, right-to-delete, audit trail with one config flag
65+
- **Auth event webhooks** — Fire HTTP callbacks on login, register, password change (for Slack notifications, analytics, etc.)
66+
- **Passwordless auth** — Magic links sent via email, no password needed
67+
- **Social login builder** — Config-driven social logins: `{ github: true, discord: true, apple: true }`
68+
69+
## 5. Evaluate & Prioritize
70+
71+
For each discovered feature:
72+
73+
| Feature | Who needs it? | Impact (1-5) | Effort (1-5) | Fits our principles? | Priority |
74+
|---|---|---|---|---|---|
75+
| ... | ... | ... | ... | Yes/No | P0-P3 |
76+
77+
A feature only qualifies if:
78+
- ✅ Stays modular (copy one folder)
79+
- ✅ Stays opt-in (disabled by default)
80+
- ✅ Benefits >20% of users
81+
- ✅ Doesn't add required dependencies
82+
83+
## 6. Write Feature Proposals
84+
85+
For the top 3 features, write a brief proposal:
86+
87+
### [Feature Name]
88+
- **What:** One paragraph description
89+
- **Why:** What problem it solves, who needs it
90+
- **How:** High-level implementation approach
91+
- **Config:** What the config option would look like
92+
- **Endpoints:** What new endpoints it would add (if any)
93+
- **Dependencies:** What new packages it would need (if any)
94+
95+
Add approved proposals to `dev-docs/future-thinking.md`.
96+
97+
```bash
98+
git add -A && git commit -m "Add feature proposals from brainstorming session"
99+
```

0 commit comments

Comments
 (0)