AI Secretary: What If You Let AI Tell You What to Do Next?

I got tired of ticketing systems. Jira, Linear, Notion boards — I've used them all, and every time the same thing happens: I spend more time organizing tasks than doing them. The backlog grows, the board gets stale, and I end up just doing whatever feels urgent anyway.

So I tried something different. What if instead of me telling a system what needs to happen, the system tells me?

The idea

I built AI Secretary — a set of AI experts that live inside my IDE and know my projects inside out. Not a chatbot. Not a task manager. More like a team of people who've read every document, every decision log, every piece of context about what I'm building, and can tell me what matters right now.

It's built on top of Cursor IDE and uses the architecture I described in Building Effective Multi-Agent AI Systems, implemented through the Architect framework.

Six experts, one conversation

Here's the thing — I don't need a project manager. I need the right perspective at the right time. So I split the AI into six roles that I switch between depending on what I'm doing:

Personal Secretary — handles daily check-ins, tracks decisions, and tells me what to do next. This is the one I talk to most. It knows my priorities and nudges me when I'm drifting.

Business Expert — when I need to think about strategy, partnerships, or where to spend limited resources. I'm a solo developer with side projects, so "business" really means "is this worth my time?"

Community Expert — manages events and community engagement. I run dance events, and this expert keeps track of who's involved, what's planned, and what needs follow-up.

Product Expert — technical guidance and architecture decisions. When I'm about to build something, this is where I gut-check the approach before writing code.

Documentation Manager — keeps docs in sync automatically. I used to let documentation rot. Now it stays current because the AI updates it as part of the workflow.

Version Control — writes commit messages and manages the git flow. Small thing, but it removes friction from one of the most common interruptions.

No ticketing system

This is the part that surprised me. I don't have a backlog. I don't have sprints. I don't have a board with columns.

The AI knows the state of everything — what's been decided, what's blocked, what's next — because it reads the same project files I work in. When I start a session, it tells me what matters today. Not what I wrote down three weeks ago in a planning meeting, but what actually matters right now based on the current state of the code and the docs.

It's a different way of thinking about work. Instead of planning everything upfront and then executing, you describe your goals and let the system figure out the sequence. Similar to the approach I use in my Personal Life Management System, but applied to code.

My seven rules

These are the rules I actually follow when working with Cursor AI. They took a few months to figure out, and they're the real heart of this workflow:

1. One task, one conversation. Keep the context small. When a conversation gets too long, the AI starts losing the thread. Start fresh for each task.

2. Documentation first. Before touching any code, I write documentation about the organization and define the goals. The AI needs to understand why before it can help with how.

3. Readme before implementation. I ask for documentation before jumping into code — Readme Driven Development. If you can't explain it in a readme, you don't understand it well enough to build it.

4. Use all six thinking hats. During implementation, I use the six thinking hats. Sometimes I agree with the AI. Sometimes I push back emotionally. Sometimes I write sarcastic comments and it adjusts. The AI responds to your energy — use that.

5. Commit after every small win. After each successful step, I git commit. This way I can try wild ideas in the next prompt without risking what already works.

6. Update docs when the task is done. After finishing a task, I ask the AI to update documentation and cross-reference everything. Docs that update themselves are docs that stay useful.

7. Build your own language. At the end of a session, I ask the AI to review our conversation and create aliases — short commands instead of long prompts. "Save" means "create a commit message and run commit." Over time, you build a shared vocabulary that makes every future session faster.

Getting started

If you want to try this yourself:

1. Clone the AI Secretary repo
2. Open it in Cursor IDE
3. Configure Claude 3 Sonnet in Cursor settings
4. Say "hi" to start the onboarding

The onboarding adapts to your role and projects. It asks what you're working on, reads your docs, and starts acting as your secretary from there.

Why this matters to me

I'm a solo developer with too many ideas and not enough hours. The question I keep coming back to is: am I working on what matters? Not what's fun, not what's easy — what matters.

A ticketing system can't answer that question. It just shows you a list and lets you pick. But an AI that knows your goals, your constraints, and the current state of your work — that can actually tell you: "this is the next thing that moves the needle."

That's what I built AI Secretary to do. It's not perfect, and the setup takes some effort. But once it's running, the feeling of sitting down and being told exactly what to do next — by something that actually understands the full picture — is hard to go back from.