agentleFS
alexeyleshchenkoalexeyleshchenko/fast-mcp-telegram/.cursor/skills/feature-development/SKILL.md

feature-development

Skill2 starsChanged 4 months agoMITView on GitHub

Feature development workflow for Telegram MCP projects. Use when implementing new features including research, planning, implementation, testing, and documentation.

  • Commits and pushes

9 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

27 rules. 0 are common, 26 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 26

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use Context7 MCP for library documentation

    line 26
  2. Distinctive:

    Use WebSearch for Telegram API specs

    line 27
  3. Distinctive:

    Use telegram-dev MCP for live API probing

    line 28
  4. Distinctive:

    Verify actual return values and structures

    line 29
  5. Distinctive:

    Check for existing tests that may break

    line 34
  6. Distinctive:

    Goal: Create a detailed, actionable plan

    line 40
  7. Distinctive:

    Ask user for specifics on behavior

    line 43
  8. Distinctive:

    Default to simplest approach

    line 45
  9. Distinctive:

    Goal: Verify assumptions with live API tests

    line 62
  10. Distinctive:

    Call methods directly and inspect raw responses

    line 67
  11. Very specific:

    Verify type definitions (e.g., TextWithEntities vs plain string)

    line 68
  12. Distinctive:

    Check field names and access patterns

    line 69
  13. Distinctive:

    Test with edge cases (empty results, invalid inputs)

    line 72
  14. Distinctive:

    Verify error handling behavior

    line 73
  15. Distinctive:

    Update plan with corrected assumptions

    line 77
  16. Distinctive:

    Don't deviate without re-planning

    line 89
  17. Distinctive:

    Use git status after each step

    line 92
  18. Distinctive:

    Goal: Verify implementation works correctly

    line 104
  19. Distinctive:

    Test new parameters/behavior

    line 107
  20. Distinctive:

    Add new tests for new behavior

    line 112
  21. Distinctive:

    Update existing tests for changed behavior

    line 113
  22. Distinctive:

    Run full test suite

    line 114
  23. Distinctive:

    Goal: Ensure code quality and documentation

    line 124
  24. Distinctive:

    Update README.md with new features

    line 132
  25. Distinctive:

    Update activeContext.md with current work

    line 154
  26. Distinctive:

    Update progress.md with completed features

    line 155
  27. Distinctive:

    Create PR: if needed

    line 171

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Feature Development Workflow

Process Overview

Research -> Plan -> Spike -> Implement -> Test -> Clean Up -> Push

Phase 1: Research

Goal: Understand the problem space and existing code

  1. Explore codebase with explore subagent:
    • Find relevant existing functions and patterns
    • Understand data structures and type definitions
    • Map relationships between components
  2. API Investigation:
    • Use Context7 MCP for library documentation
    • Use WebSearch for Telegram API specs
    • Use telegram-dev MCP for live API probing
    • Verify actual return values and structures
  3. Edge Case Identification:
    • Identify potential issues early
    • Note API limitations or quirks
    • Check for existing tests that may break

Phase 2: Planning

Goal: Create a detailed, actionable plan

  1. Clarify Requirements:
    • Ask user for specifics on behavior
    • Offer numbered options for implementation choices
    • Default to simplest approach
  2. Document Technical Findings:
    • API behavior verified through research
    • Type structures and field access patterns
    • Known limitations and edge cases
  3. Create Plan (use CreatePlan tool):
    • Numbered steps with specific file:line references
    • Code snippets for key changes
    • Mermaid diagrams for complex relationships
    • Complexity assessment table

Phase 3: Spiking

Goal: Verify assumptions with live API tests

Use telegram-dev MCP for live testing:

  1. API Response Structure:
    • Call methods directly and inspect raw responses
    • Verify type definitions (e.g., TextWithEntities vs plain string)
    • Check field names and access patterns
  2. Edge Cases:
    • Test with edge cases (empty results, invalid inputs)
    • Verify error handling behavior
    • Confirm caching behavior if applicable
  3. Document Findings:
    • Update plan with corrected assumptions
    • Note any API quirks or bugs
    • Identify potential issues before implementation

Phase 4: Implementation

Goal: Execute the plan faithfully

  1. Follow Plan Steps in order:
    • Make changes as specified in plan
    • Don't deviate without re-planning
  2. Track Progress:
    • Use git status after each step
    • Verify expected changes
  3. Code Standards:
    • No linter errors
    • No redundant comments
    • Follow existing patterns

Phase 5: Testing

Goal: Verify implementation works correctly

  1. Live API Tests (via telegram-dev MCP):
    • Test new parameters/behavior
    • Verify error handling
    • Check edge cases
  2. Unit Tests:
    • Add new tests for new behavior
    • Update existing tests for changed behavior
    • Run full test suite
  3. Document Results:
    • Note any issues found
    • Fix bugs discovered

Phase 6: Clean Up

Goal: Ensure code quality and documentation

  1. Code Cleanup (use code-cleanup-specialist subagent):
    • Run linter checks
    • Fix code quality issues
    • Verify tests pass
  2. Documentation Update:

    • Update README.md with new features
    • Update docs/ folder
    • Use feature template:
    ### [Feature Name]
    
    **Tool/Function**: [name]
    
    **Parameters**:
    - `[param]`: [type] - [description]
    
    **Values**:
    - [value 1]: [description]
    
    **Example**:
    ```[lang]
    [example code]
  3. Memory Bank Update:
    • Update activeContext.md with current work
    • Update progress.md with completed features
    • Document key decisions

Phase 7: Git Push

  1. Commit with descriptive message:
    [type]: [brief description]
    
    [detailed changes if needed]
  2. Push to remote
  3. Create PR if needed

Example: Adding Folder Filtering Feature

Research

  • Explored src/tools/chat_discovery/ for existing dialog iteration
  • Used Context7 to verify iter_dialogs folder parameter
  • Used WebSearch to find DialogFilter TL schema

Spike

  • Called GetDialogFiltersRequest via telegram-dev
  • Discovered title is TextWithEntities object (not string)
  • Discovered folder_id=0 shows as null on Dialog objects

Plan

  • Created step-by-step plan
  • Documented TextWithEntities extraction
  • Added note about folder_id=null behavior

Implement

  • Added get_available_folders() with caching
  • Added _resolve_folder_id() helper
  • Updated iter_dialogs calls with folder param

Test

  • Live tested folder="Бридж" - worked
  • Live tested folder=1 - worked
  • Fixed cache key bug (SQLiteSession issue)

Clean Up

  • Ran code-cleanup-specialist
  • Updated README.md
  • Updated docs/Tools-Reference.md
  • Updated memory bank

Push

  • Committed with descriptive message
  • Pushed to origin

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.