A step-by-step guide to vibe-code new features with AI (include prompt examples)

Let’s imagine you use a PHP authentication package in your project. It handles login and registration well. But you need email verification — and the library doesn’t have this feature. You want to help the maintainers add these features. But contributing feels scary and complicated.

Sounds familiar?

Why It’s Hard to Contribute

Contributing to open source has several problems:

1. You don’t understand their code: The library works for basic needs. But how do you add new features to their code structure? You need to learn their patterns first.
2. Language problems: You need to write in other language. You need to explain what feature is missing and why it’s important. This is hard for many developers.
3. You worry about rejection: What if maintainers don’t want your feature? What if they think it’s not important? These fears stop you from trying.

A Step-by-Step guide

I’ve been working on open source projects for many years (GitHub profile). During this time, I developed a complete framework for myself to contribute features safely and confidently. I want to share this framework with everyone to make open source better and help developers not be afraid of this process.

Here is a simple guide to suggest and add missing features. It breaks the work into small steps. Each step has clear goals.

Step 1: Study the library you use

First, you need to understand how the library works inside. Don’t read files manually. Use tools to get the full picture quickly.

For collecting contexts, I use the CTX library that I developed some time ago. It’s perfect for studying other developers’s codebases quickly and systematically. Full docs here.

Create a context file to study the library:

# context.yaml

documents:
  - description: "How the library is organized"
    outputPath: "study/library-structure.md"
    sources:
      - type: tree
        description: "File structure"
        sourcePaths:- src

      - type: file
        description: "Main auth files"
        sourcePaths: 
           - src
        path: ["Auth", "Security", "User"]
        filePattern: "*.php"

  - description: "How they handle emails currently"
    outputPath: "study/email-system.md"  
    sources:
      - type: file
        description: "Email code"
        sourcePaths: 
           - src
        contains: ["email", "mail", "send"]
        filePattern: "*.php"

Ask AI to explain the library:

You are an expert PHP developer analyzing authentication libraries.

**Task:** Study a PHP auth library and explain how to add email verification.
**Input:** Context files showing library structure and auth-related code.
**Process:**
1. **Understand the library** - How is it organized? What patterns does it use?
2. **Map current registration** - How do users register now? What's the flow?
3. **Find integration points** - Where would email verification fit?
4. **Plan implementation** - What needs to be built?

**Output:**

## How the Library Works
- Main components and their roles
- Current user registration process
- Design patterns used

## Registration Flow Diagram
```mermaid
[Simple class diagram of current registration]
```

## Email Verification Plan
- Database changes needed
- New classes to create  
- Where to hook into existing code
- Step-by-step implementation

## Security Notes
- Token handling requirements
- Rate limiting considerations

**If you can't determine something from the code:** 
Say so and explain what additional info you'd need.

Remember to upload both the planning files you created above AND the context files generated in Step 1 (library structure and email systems). This gives AI the complete picture to create a proper feature plan.

After this step, you understand the library structure and where your feature could fit.

Step 2: Plan the missing feature

Now plan how email verification would fit with the library’s code. Think about how it should work with their existing system.

In this step, you use the context collected in Step 1. Your goal is to prepare instructions for AI that will help you create a complete feature request.

Use the following instruction to ask AI to write implementation plan:

You are an expert in PHP library design and feature planning for open source 
projects.

**Task:** Create a detailed implementation plan for adding email verification 
to an existing PHP authentication library that can be used as a Feature Request.

**Input:**
- Library architecture and patterns
- [Attached files]

**Process:**
1. **Review existing architecture** - What patterns should the new feature 
follow?
2. **Design integration points** - Where does email verification hook in?
3. **Plan database layer** - What tables/columns are needed?
4. **Define public API** - What methods will developers use?
5. **Consider configuration** - How to make it optional and flexible?

**Output:**

## Implementation Plan

### New Classes Needed
```
EmailVerificationService
├── Purpose: Handle verification logic
├── Methods: send(), verify(), resend()
└── Depends on: [existing services it needs]

EmailVerificationToken
├── Purpose: Token model/entity
├── Properties: token, user_id, expires_at, created_at
└── Methods: isExpired(), generate()

[List other classes...]
```

### Database Changes
```sql
-- Migration: add_email_verification_table
CREATE TABLE email_verification_tokens (
    -- columns needed
);

-- Migration: add_verified_column_to_users  
ALTER TABLE users ADD COLUMN email_verified_at TIMESTAMP NULL;
```

### Integration Points
- **During Registration:** [Where to hook in verification email sending]
- **Login Check:** [Where to verify email status before allowing login]
- **New Routes:** [What endpoints need to be added]

### Configuration Options
```php
// How developers will configure the feature
'email_verification' => [
    'enabled' => true,
    'token_expiry' => 3600, // 1 hour
    'required_for_login' => false,
    'resend_limit' => 3,
]
```

### Public API Design
```php
// How developers will use the feature
$auth->requireEmailVerification();
$auth->sendVerificationEmail($user);
$auth->verifyEmail($token);
```

### Testing Strategy
- **Unit Tests:** [Classes that need individual testing]
- **Integration Tests:** [Full flow testing scenarios]
- **Edge Cases:** [What could go wrong and how to test it]

### Backwards Compatibility
- How existing users are handled
- Migration strategy for current installations
- Default settings that don't break existing code

### Open Questions
- [Things you need library maintainer input on]
- [Decisions that could go multiple ways]

Now you have a clear implementation plan.

Step 3: Suggest the feature to maintainers

At this stage, you already have our feature request document from Step 2 and the codebase context from Step 1. Now you can add project documentation (README.md, CONTRIBUTING.mdfiles) to your contexts, check what files exist, and combine everything together. Then you pass all this to AI with the instructions below and ask it to write a GitHub issue text.

# context.yaml
documents:

  # Contexts from Step 1 ...

  - description: "Similar features they have"
    outputPath: "request/examples.md"
    sources:
      - type: file
        description: 
           - src
        contains: ["password", "reset", "token"]
        filePattern: "*.php"
      
      - type: file
        description: "Library docs"
        sourcePaths: 
            - README.md
            - CONTRIBUTING.md

Use the following instruction to write feature request:

You are an expert at writing GitHub feature requests that get positive responses from open source maintainers.

**Task:** Write a GitHub issue requesting email verification feature for a PHP authentication library.

**Input:** 
- Context files showing similar features in the library
- Your implementation plan from Step 2
- Library documentation and contribution guidelines

**Process:**
1. **Study their style** - How do they write issues? What tone do they use?
2. **Find similar features** - What patterns exist for tokens/verification?
3. **Write user-focused request** - Why do developers need this?
4. **Show technical understanding** - Prove you know the codebase
5. **Offer help** - Make it easy for them to say yes

**Output:**

## GitHub Issue Template

### Title
[Feature Request] Add Email Verification Support

### Issue Body

**Problem**
Many developers using this library need to verify user email addresses before allowing full access. Right now, users have to build this themselves or use separate packages.

**Use Cases**
- SaaS apps that need verified emails for billing
- Community platforms preventing spam accounts  
- Any app following security best practices

**Proposed Solution**
Add optional email verification that follows the library's existing patterns. I've studied how you handle password resets and would use similar approach.

**Basic Implementation Plan**
- New `EmailVerificationService` (similar to existing password reset)
- Database table for verification tokens (like you do for password tokens)
- Optional config setting (disabled by default for backwards compatibility)
- Hook into registration flow

**Integration Example**
```php
// How developers would use it
$auth->enableEmailVerification();
$user = $auth->register($data); // automatically sends verification email
$auth->verifyEmail($token); // verify from email link
```

**I can help implement this**
I've analyzed the codebase and created a detailed plan. Happy to:
- Write the code following your patterns
- Add comprehensive tests
- Update documentation
- Handle backwards compatibility

Would you be interested in this feature? I can adjust the approach based on your preferences.

**Quality Elements:**
- Starts with user problem, not technical solution
- Shows understanding of existing codebase patterns
- Offers specific help rather than just requesting
- Keeps technical details brief but shows competence
- Makes it easy for maintainers to say "yes, but change X"

**Tone Guidelines:**
- Friendly and helpful, not demanding
- Shows respect for maintainer time
- Demonstrates you've done homework first
- Offers collaboration, not just feature requests

When AI generates the issue text, your job is to read it and check if everything is written correctly. You might need to add clarifying details, discuss them with the LLM, or provide missing context if something is wrong. After this, you can publish it on the GitHub issues page and clarify details with the maintainers, or start working on a pull request if you don’t want to wait.

Language support: AI helps translate your technical understanding into professional English, ensuring your issue description is clear, comprehensive, and culturally appropriate for the project’s community. Crucially, it helps frame problems as collaborative opportunities rather than criticisms, maintaining the respectful tone that successful open-source communication requires.

Step 4: Write the code

When maintainers approve the feature idea, start the coding process.

Prepare for coding:

1. First, commit all changes in your cloned repo, so you have a clean working state
2. Start a session with AI using a specialized instruction (example below)
3. Provide the AI with:

• Codebase context from Step 1
• Feature request document from Step 3
• Any additional necessary context

Use the following instruction to implement a new feature:

First analyze attached files, then follow the following instruction

You are an expert in writing PHP code. You love your work and 
always aim for clean, efficient, and well-structured PHP code, focusing on 
detail and best practices.

### **Guidelines for PHP Code Generation:**

1. **Use PHP 8.3 Features:**  
   - Use **constructor property promotion** to keep class definitions simple.  
   - Use **named arguments** for better readability and flexibility.  
   - **Avoid annotations**; prefer native PHP constructs instead.

2. **Plan Before Coding:**  
   - **Never write any code before providing a clear file structure** for the 
   new classes.  
   - **First, explain your idea** clearly, describing class hierarchy and 
   relationships.  
   - Present the hierarchy like this:
     ```
     ExampleBaseClass (abstract base class)
     ├── FooBaseClass (some foo class description)
     └── AnotherBaseClass (another class description)
     ```

   IMPORTANT:  hierarchy structure is a simple example, DO NOT USE IT AS 
   IS!

   - Briefly explain the purpose and role of each class before writing code.

3. **Code Generation Rules:**  
   - Only generate code when explicitly asked, and always stick to the 
   planned structure.
   - Keep your code **modular**, **extensible**, and **clean**.
   - Always use **strict types** and prefer **immutable data**.

4. **Editing Existing Code:**  
   - **Provide only the necessary changes** when modifying existing code. 
   Don't rewrite entire files.
   - Clearly state what's been changed and why, keeping your edits minimal 
   and precise.
   - Maintain the original coding style and structure.

5. **Request Additional Information if Needed:**
   - If there's not enough information about existing APIs (interfaces or 
   classes mentioned in provided code), don't guess or proceed immediately.
   - **Always ask explicitly for the missing information** before starting to 
   write any code.

Implementation options:

• If you use MCP server, AI can write code directly to your project files (CTX supports this, by the way)
• If not, manually copy-paste the generated code into your local files

Iterative development: After AI generates code, verify the changes and test them. If something doesn’t work or needs improvement, continue the iterative process with AI until your code is working properly. Each iteration builds on the previous one, gradually improving the implementation.

After each iteration, commit your changes. This helps you track progress and makes it easy to go back if something breaks.

Context management: Maintain updated project context throughout development to ensure AI assistance remains relevant and accurate.

Implementation documentation process: For complex features requiring multiple development sessions, collect session summaries into a unified document. This comprehensive change log becomes the foundation for future commit messages and pull-request descriptions. The AI-generated session summaries ensure no important implementation details are lost and provide rich context for crafting compelling PR narratives.

Key output: Working implementation with comprehensive documentation of all changes and the reasoning behind implementation decisions, ready for professional presentation.

Step 5: Create Pull Request

Complete the contribution with creating PR:

1. Using your collected session summaries, work with AI to craft a pull request description that tells the complete story of your implementation
2. Update README files and relevant documentation
3. When maintainers ask questions during review, return to your original implementation sessions with AI. Copy their questions into the session context where the relevant code was developed, allowing AI to help craft detailed, contextually-aware responses that demonstrate deep understanding of both the changes and the reasoning behind them.

Use the following instruction to create PR:

Write a comprehensive pull request description for email verification 
feature.

**Context:** [Upload implementation story and planning docs]

**Structure:**
## Summary
Brief explanation of what this PR adds

## Implementation Details  
- Classes created and their purpose
- Database migrations included
- Configuration options added
- Integration points with existing code

## Testing
- Unit tests added
- Integration scenarios covered
- Manual testing performed

## Documentation
- README updates made
- Code comments added
- Usage examples provided

## Backwards Compatibility
- How existing installations are handled
- Default settings that preserve current behavior
- Migration path for existing users

## Review Notes
- Areas that need particular attention
- Design decisions that could be discussed
- Trade-offs made and reasoning

Keep it detailed but scannable. Use code examples to show key features.

Use the following instruction to update README:

You are an expert technical writer updating library documentation.

**Task:** Add email verification feature to the existing README while
 maintaining consistency with the current style.

**Input:** 
- Current README.md file
- Email verification implementation code
- Configuration options and usage examples

**Process:**
1. **Analyze existing style** - How are features described? What's the tone?
2. **Find insertion points** - Where should email verification be mentioned?
3. **Create consistent content** - Match formatting, code style, and 
explanation depth
4. **Verify completeness** - Cover installation, config, usage, troubleshooting

Step 6: Work with reviewers

Maintainers will read your code and ask questions. Answer them clearly.

Use the following instruction for review responses:

Help me respond to code review comments professionally and thoroughly.

Review comment: "[Copy exact comment from maintainer]"

Context: [Upload implementation context and decision context]

Provide:
1. Clear acknowledgment of their concern
2. Explanation of the current implementation approach
3. Reasoning behind the decision (from planning phase)
4. Proposed solution or alternative if they're suggesting changes
5. Any additional context that helps them understand the choice

Keep responses:
- Professional and collaborative
- Detailed enough to show understanding
- Open to their suggestions
- Focused on the specific concern raised

How to Talk to Maintainers

Good communication is very important. Here are examples:

Bad way: “Your project needs email verification. I will add it.”

Good way: “I use your library and it’s great! I need email verification feature for my project. Many other users probably need this too. I studied your code and can add this feature following your patterns. Would you like me to create a PR for you to review?”

Bad way: “Your library has a security problem without email verification.”

Good way: “Email verification would make your library even more secure and complete. I can help implement this feature if you think it’s useful.”

Always be polite and helpful. Show that you respect the library and want to improve it for everyone.

Common Mistakes to Avoid

Don’t start coding first: Always talk to maintainers before you write code. They might not want the feature, or they might have different ideas.

Don’t ignore their patterns: Study how they organize code. Make your code match their style.

Don’t make big changes: Start with simple, basic features. Big changes are harder to review.

Don’t disappear: Answer questions quickly. Help with the review process.

Tools You Need

1. CTX: Creates context files automatically. Instead of reading many files manually, CTX collects the right information for you.
2. Claude or ChatGPT: Helps you understand code, plan features, and write good explanations in English.
3. Git: Normal version control to track your changes.

The Power of Context

The key to this framework is giving AI the right information. When you provide complete context about the library, your feature plan, and your goals, AI can give you much better help.

If you ask LLM for directions without telling it where you are or where you want to go, it can’t help you much. But if you give it complete information, it can give you the exact route.

Conclusion

Open source doesn’t have to be scary. You already use libraries that need features. You have ideas that can help other developers. This guide shows you exactly how to turn those ideas into real contributions.

The secret is simple: prepare good context, work with AI, and follow the steps. Each step builds on the previous one. By the end, you’ll have professional code that maintainers want to merge.

Start with one library you use. Find one missing feature. Follow these 6 steps. You’ll be surprised how good it feels to help improve the tools we all depend on.

Your first contribution is just 6 steps away.

About CTX

I developed the CTX tool because I needed to generate proper context for LLMs to solve real problems and write better code for my projects. It started as a personal solution but proved so useful that I decided to share it with the community.

If you found CTX helpful in this guide, join our Discord community! It’s still new and small, but it would be great to have you there asking questions and sharing your ideas. We’re building a space where developers can share context configurations, AI workflows, and help each other create better contexts.

🚀 Join CTX Discord Community