Most articles about AI coding assistants focus on writing code faster.
But when you join a new company or project, the real problem isn't writing code.
The real problem is:
"I have no idea how this system works."
Recently, I joined a project that had been under development for several years. The codebase consisted of multiple repositories, multiple services, shared libraries, integrations, and a lot of historical decisions.
My first thought was:
"How do I use Cursor without wasting tokens and without asking the same questions repeatedly?"
After some experimentation, I developed a workflow that turns Cursor into an onboarding engineer, architect, documentation writer, and ticket assistant.
This post explains the exact setup.
The Mistake Most Developers Make
When joining a large project, many developers immediately ask Cursor:
Analyze the entire project.
Or:
Explain this codebase.
This usually leads to:
- Huge token usage
- Generic answers
- Lost context
- Repeated analysis
- Poor ticket understanding
The problem is simple:
Cursor cannot remember an entire enterprise system forever.
Instead of repeatedly scanning the codebase, you need to build a knowledge base.
Treat Cursor Like a New Team Member
Imagine a new engineer joins your team.
You wouldn't tell them:
Read 50 repositories and memorize everything.
You would create:
- Architecture docs
- Repository maps
- Service relationships
- Learning plans
That's exactly what Cursor needs too.
Step 1: Create an Onboarding Mission
Instead of asking Cursor random questions, give it a clear responsibility:
Understand the system.
Document the system.
Teach me the system.
I created a dedicated onboarding mission that instructed Cursor to:
- Discover repositories
- Map architecture
- Document service relationships
- Create learning plans
- Build a central knowledge base
The goal was not writing code.
The goal was understanding the project.
Step 2: Create a Central Knowledge Base
I created:
docs/onboarding/
The most important file became:
docs/onboarding/project-memory.md
This file contains:
- Repository purposes
- Architecture notes
- Service relationships
- Business domains
- Coding conventions
- Important discoveries
- Frequently touched files
Think of it as your project's internal wiki.
Step 3: Document the System Before Coding
Cursor generated:
docs/onboarding/
repositories-overview.md
system-architecture.md
learning-order.md
project-memory.md
progress.md
onboarding-audit.md
For each repository:
docs/onboarding/<repo-name>/
overview.md
architecture.md
important-files.md
request-flow.md
common-patterns.md
integrations.md
The objective was simple:
Never learn the same thing twice.
Step 4: Stop Scanning the Entire Workspace
One of the biggest token-saving techniques:
Never do this:
Analyze the entire workspace.
Instead:
Read project-memory.md first.
Analyze only affected repositories.
This single change dramatically reduced context usage.
Step 5: Configure Cursor Rules
I added a project rule:
Before analyzing code:
1. Read onboarding documentation first.
2. Use project-memory.md as primary context.
3. Analyze only affected repositories.
4. Avoid scanning the entire workspace.
5. Create an implementation plan before coding.
6. Update documentation when new knowledge is discovered.
Now Cursor automatically follows this workflow.
Step 6: Create Reusable Skills
Instead of writing long prompts repeatedly, I created Cursor Skills.
/ticket
Used when a new ticket arrives.
Responsibilities:
- Read project memory
- Identify affected repositories
- Explain current behavior
- Create implementation plan
- Assess risks
No coding yet.
/implement
Used after the plan is approved.
Responsibilities:
- Explain changes
- Modify only required files
- Follow existing patterns
- Minimize impact
/review
Used after implementation.
Responsibilities:
- Review architecture compliance
- Check edge cases
- Review error handling
- Verify backward compatibility
/update-docs
Used after ticket completion.
Responsibilities:
- Update project memory
- Update architecture docs
- Record new discoveries
/audit
Used periodically.
Responsibilities:
- Measure onboarding coverage
- Find undocumented repositories
- Identify knowledge gaps
/learn
Used daily.
Responsibilities:
- Pick the next important module
- Explain request flows
- Explain database interactions
- Explain integrations
- Teach the system incrementally
My Daily Workflow
When onboarding:
/continue
When learning:
/learn
When checking progress:
/audit
When a ticket arrives:
/ticket
After approval:
/implement
Before merging:
/review
After completion:
/update-docs
The Biggest Benefit
Most developers use Cursor as a coding assistant.
I started using Cursor as a project knowledge assistant.
That changed everything.
Instead of repeatedly asking:
Where is this code?
I started asking:
What does the system know already?
The result:
- Faster onboarding
- Better architectural understanding
- Lower token usage
- Better ticket analysis
- Consistent documentation
- Less context loss
Final Thoughts
If you're joining a large legacy project with multiple repositories and almost zero domain knowledge, don't start by generating code.
Start by building knowledge.
Use Cursor to:
- Map the system.
- Document the system.
- Teach the system.
- Maintain the knowledge base.
- Then write code.
Once your documentation becomes mature, Cursor stops being just an AI coding assistant.
It becomes a long-term engineering partner that understands your project almost as well as your team does.
