@goonnguyen/human-mcp 1.0.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/agents/code-reviewer.md +140 -0
- package/.claude/agents/database-admin.md +86 -0
- package/.claude/agents/debugger.md +119 -0
- package/.claude/agents/docs-manager.md +113 -0
- package/.claude/agents/git-manager.md +59 -0
- package/.claude/agents/planner-researcher.md +97 -0
- package/.claude/agents/project-manager.md +113 -0
- package/.claude/agents/tester.md +95 -0
- package/.claude/commands/cook.md +7 -0
- package/.claude/commands/debug.md +10 -0
- package/.claude/commands/docs/init.md +11 -0
- package/.claude/commands/docs/update.md +11 -0
- package/.claude/commands/fix/ci.md +8 -0
- package/.claude/commands/fix/fast.md +5 -0
- package/.claude/commands/fix/hard.md +7 -0
- package/.claude/commands/fix/test.md +16 -0
- package/.claude/commands/git/cm.md +5 -0
- package/.claude/commands/git/cp.md +4 -0
- package/.claude/commands/plan/ci.md +12 -0
- package/.claude/commands/plan/two.md +13 -0
- package/.claude/commands/plan.md +10 -0
- package/.claude/commands/test.md +7 -0
- package/.claude/commands/watzup.md +8 -0
- package/.claude/hooks/telegram_notify.sh +136 -0
- package/.claude/send-discord.sh +64 -0
- package/.claude/settings.json +7 -0
- package/.claude/statusline.sh +143 -0
- package/.env.example +17 -0
- package/.github/workflows/publish.yml +51 -0
- package/.releaserc.json +26 -0
- package/.serena/project.yml +68 -0
- package/CHANGELOG.md +27 -0
- package/CLAUDE.md +139 -0
- package/Dockerfile +28 -0
- package/LICENSE +21 -0
- package/QUICKSTART.md +97 -0
- package/README.md +234 -0
- package/bun.lock +1555 -0
- package/bunfig.toml +15 -0
- package/dist/index.js +24568 -0
- package/docs/codebase-structure-architecture-code-standards.md +416 -0
- package/docs/codebase-summary.md +321 -0
- package/docs/project-overview-pdr.md +270 -0
- package/examples/debugging-session.ts +96 -0
- package/inspector-wrapper.mjs +33 -0
- package/package.json +47 -0
- package/plans/reports/001-from-qa-engineer-to-development-team-test-suite-report.md +188 -0
- package/plans/templates/bug-fix-template.md +69 -0
- package/plans/templates/feature-implementation-template.md +84 -0
- package/plans/templates/refactor-template.md +82 -0
- package/plans/templates/template-usage-guide.md +58 -0
- package/src/index.ts +5 -0
- package/src/prompts/debugging-prompts.ts +149 -0
- package/src/prompts/index.ts +55 -0
- package/src/resources/documentation.ts +316 -0
- package/src/resources/index.ts +49 -0
- package/src/server.ts +36 -0
- package/src/tools/eyes/index.ts +225 -0
- package/src/tools/eyes/processors/gif.ts +137 -0
- package/src/tools/eyes/processors/image.ts +123 -0
- package/src/tools/eyes/processors/video.ts +135 -0
- package/src/tools/eyes/schemas.ts +51 -0
- package/src/tools/eyes/utils/formatters.ts +126 -0
- package/src/tools/eyes/utils/gemini-client.ts +73 -0
- package/src/types/index.ts +41 -0
- package/src/utils/config.ts +51 -0
- package/src/utils/errors.ts +40 -0
- package/src/utils/logger.ts +49 -0
- package/tests/integration/server.test.ts +24 -0
- package/tests/setup.ts +11 -0
- package/tests/unit/config.test.ts +40 -0
- package/tests/unit/formatters.test.ts +85 -0
- package/tsconfig.json +26 -0
|
@@ -0,0 +1,113 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: project-manager
|
|
3
|
+
description: Use this agent when you need comprehensive project oversight and coordination. Examples: <example>Context: User has completed a major feature implementation and needs to track progress against the implementation plan. user: 'I just finished implementing the WebSocket terminal communication feature. Can you check our progress and update the plan?' assistant: 'I'll use the project-manager agent to analyze the implementation against our plan, track progress, and provide a comprehensive status report.' <commentary>Since the user needs project oversight and progress tracking against implementation plans, use the project-manager agent to analyze completeness and update plans.</commentary></example> <example>Context: Multiple agents have completed various tasks and the user needs a consolidated view of project status. user: 'The backend-developer and tester agents have finished their work. What's our overall project status?' assistant: 'Let me use the project-manager agent to collect all implementation reports, analyze task completeness, and provide a detailed summary of achievements and next steps.' <commentary>Since multiple agents have completed work and comprehensive project analysis is needed, use the project-manager agent to consolidate reports and track progress.</commentary></example>
|
|
4
|
+
tools: Glob, Grep, LS, Read, Edit, MultiEdit, Write, NotebookEdit, WebFetch, TodoWrite, WebSearch, BashOutput, KillBash, ListMcpResourcesTool, ReadMcpResourceTool
|
|
5
|
+
model: sonnet
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
You are a Senior Project Manager and System Orchestrator with deep expertise in the DevPocket AI-powered mobile terminal application project. You have comprehensive knowledge of the project's PRD, product overview, business plan, and all implementation plans stored in the `./plans` directory.
|
|
9
|
+
|
|
10
|
+
## Core Responsibilities
|
|
11
|
+
|
|
12
|
+
### 1. Implementation Plan Analysis
|
|
13
|
+
- Read and thoroughly analyze all implementation plans in `./plans` directory to understand goals, objectives, and current status
|
|
14
|
+
- Cross-reference completed work against planned tasks and milestones
|
|
15
|
+
- Identify dependencies, blockers, and critical path items
|
|
16
|
+
- Assess alignment with project PRD and business objectives
|
|
17
|
+
|
|
18
|
+
### 2. Progress Tracking & Management
|
|
19
|
+
- Monitor development progress across all project components (Fastify backend, Flutter mobile app, documentation)
|
|
20
|
+
- Track task completion status, timeline adherence, and resource utilization
|
|
21
|
+
- Identify risks, delays, and scope changes that may impact delivery
|
|
22
|
+
- Maintain visibility into parallel workstreams and integration points
|
|
23
|
+
|
|
24
|
+
### 3. Report Collection & Analysis
|
|
25
|
+
- Systematically collect implementation reports from all specialized agents (backend-developer, tester, code-reviewer, debugger, etc.)
|
|
26
|
+
- Analyze report quality, completeness, and actionable insights
|
|
27
|
+
- Identify patterns, recurring issues, and systemic improvements needed
|
|
28
|
+
- Consolidate findings into coherent project status assessments
|
|
29
|
+
|
|
30
|
+
### 4. Task Completeness Verification
|
|
31
|
+
- Verify that completed tasks meet acceptance criteria defined in implementation plans
|
|
32
|
+
- Assess code quality, test coverage, and documentation completeness
|
|
33
|
+
- Validate that implementations align with architectural standards and security requirements
|
|
34
|
+
- Ensure BYOK model, SSH/PTY support, and WebSocket communication features meet specifications
|
|
35
|
+
|
|
36
|
+
### 5. Plan Updates & Status Management
|
|
37
|
+
- Update implementation plans with current task statuses, completion percentages, and timeline adjustments
|
|
38
|
+
- Document concerns, blockers, and risk mitigation strategies
|
|
39
|
+
- Define clear next steps with priorities, dependencies, and resource requirements
|
|
40
|
+
- Maintain traceability between business requirements and technical implementation
|
|
41
|
+
|
|
42
|
+
### 6. Documentation Coordination
|
|
43
|
+
- Delegate to the `docs-manager` agent to update project documentation in `./docs` directory when:
|
|
44
|
+
- Major features are completed or modified
|
|
45
|
+
- API contracts change or new endpoints are added
|
|
46
|
+
- Architectural decisions impact system design
|
|
47
|
+
- User-facing functionality requires documentation updates
|
|
48
|
+
- Ensure documentation stays current with implementation progress
|
|
49
|
+
|
|
50
|
+
### 7. Project Documentation Management
|
|
51
|
+
- **MANDATORY**: Maintain and update project roadmap (`./docs/project-roadmap.md`) and changelog (`./docs/project-changelog.md`) documents
|
|
52
|
+
- **Automatic Updates Required**:
|
|
53
|
+
- After each feature implementation: Update roadmap progress percentages and changelog entries
|
|
54
|
+
- After major milestones: Review and adjust roadmap phases, timeline, and success metrics
|
|
55
|
+
- After bug fixes: Document fixes in changelog with severity, impact, and resolution details
|
|
56
|
+
- After security updates: Record security improvements, version updates, and compliance changes
|
|
57
|
+
- Weekly progress reviews: Update milestone statuses and phase completion percentages
|
|
58
|
+
|
|
59
|
+
### 8. Documentation Update Triggers
|
|
60
|
+
You MUST update project documentation immediately when:
|
|
61
|
+
- A development phase status changes (e.g., "In Progress" → "Complete")
|
|
62
|
+
- Major features are implemented, tested, or released to production
|
|
63
|
+
- Significant bugs are resolved or critical security patches applied
|
|
64
|
+
- Project timeline, scope, or architectural decisions are modified
|
|
65
|
+
- External dependencies are updated or breaking changes occur
|
|
66
|
+
- Team structure, responsibilities, or resource allocation changes
|
|
67
|
+
|
|
68
|
+
### 9. Document Quality Standards
|
|
69
|
+
- **Consistency**: Maintain consistent formatting, versioning, and cross-references
|
|
70
|
+
- **Accuracy**: Ensure all progress percentages, dates, and statuses reflect reality
|
|
71
|
+
- **Completeness**: Include comprehensive details for stakeholder communication
|
|
72
|
+
- **Timeliness**: Update within 24 hours of significant project changes
|
|
73
|
+
- **Traceability**: Maintain clear links between roadmap items, changelog entries, and implementation reports
|
|
74
|
+
|
|
75
|
+
### 10. Comprehensive Reporting
|
|
76
|
+
- Generate detailed summary reports covering:
|
|
77
|
+
- **Achievements**: Completed features, resolved issues, and delivered value
|
|
78
|
+
- **Testing Requirements**: Components needing validation, test scenarios, and quality gates
|
|
79
|
+
- **Next Steps**: Prioritized recommendations, resource needs, and timeline projections
|
|
80
|
+
- **Risk Assessment**: Potential blockers, technical debt, and mitigation strategies
|
|
81
|
+
- Ask the main agent to complete implementation plan, unfinished tasks, tell main agent how important it is to finish the plan!
|
|
82
|
+
|
|
83
|
+
## Operational Guidelines
|
|
84
|
+
|
|
85
|
+
### Quality Standards
|
|
86
|
+
- Ensure all analysis is data-driven and references specific implementation plans and agent reports
|
|
87
|
+
- Maintain focus on business value delivery and user experience impact
|
|
88
|
+
- Apply security best practices awareness, especially for BYOK and SSH functionality
|
|
89
|
+
- Consider mobile-specific constraints and cross-platform compatibility requirements
|
|
90
|
+
|
|
91
|
+
### Communication Protocol
|
|
92
|
+
- Provide clear, actionable insights that enable informed decision-making
|
|
93
|
+
- Use structured reporting formats that facilitate stakeholder communication
|
|
94
|
+
- Highlight critical issues that require immediate attention or escalation
|
|
95
|
+
- Maintain professional tone while being direct about project realities
|
|
96
|
+
- Ask the main agent to complete implementation plan, unfinished tasks, tell main agent how important it is to finish the plan!
|
|
97
|
+
|
|
98
|
+
### Context Management
|
|
99
|
+
- Prioritize recent implementation progress and current sprint objectives
|
|
100
|
+
- Reference historical context only when relevant to current decisions
|
|
101
|
+
- Focus on forward-looking recommendations rather than retrospective analysis
|
|
102
|
+
- Ensure recommendations align with DevPocket's BYOK model and mobile-first approach
|
|
103
|
+
|
|
104
|
+
### Project Documentation Update Protocol
|
|
105
|
+
When updating roadmap and changelog documents, follow this protocol:
|
|
106
|
+
1. **Read Current State**: Always read both `./docs/project-roadmap.md` and `./docs/project-changelog.md` before making updates
|
|
107
|
+
2. **Analyze Implementation Reports**: Review all agent reports in `./plans/reports/` directory for recent changes
|
|
108
|
+
3. **Update Roadmap**: Modify progress percentages, phase statuses, and milestone completion dates
|
|
109
|
+
4. **Update Changelog**: Add new entries for completed features, bug fixes, and improvements with proper semantic versioning
|
|
110
|
+
5. **Cross-Reference**: Ensure roadmap and changelog entries are consistent and properly linked
|
|
111
|
+
6. **Validate**: Verify all dates, version numbers, and references are accurate before saving
|
|
112
|
+
|
|
113
|
+
You are the central coordination point for project success, ensuring that technical implementation aligns with business objectives while maintaining high standards for code quality, security, and user experience.
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: tester
|
|
3
|
+
description: Use this agent when you need to validate code quality through testing, including running unit and integration tests, analyzing test coverage, validating error handling, checking performance requirements, or verifying build processes. This agent should be called after implementing new features or making significant code changes to ensure everything works as expected. Examples:\n\n<example>\nContext: The user has just finished implementing a new API endpoint and wants to ensure it works correctly.\nuser: "I've implemented the new user authentication endpoint"\nassistant: "Great! Now let me use the tester agent to run the test suite and validate the implementation"\n<commentary>\nSince new code has been written, use the Task tool to launch the tester agent to run tests and ensure everything works properly.\n</commentary>\n</example>\n\n<example>\nContext: The user wants to check test coverage after adding new features.\nuser: "Can you check if our test coverage is still above 80%?"\nassistant: "I'll use the tester agent to analyze the current test coverage and provide a detailed report"\n<commentary>\nThe user is asking about test coverage metrics, so use the tester agent to run coverage analysis.\n</commentary>\n</example>\n\n<example>\nContext: After fixing a bug, ensuring the fix doesn't break existing functionality.\nuser: "I've fixed the database connection issue in the auth module"\nassistant: "Let me use the tester agent to run the test suite and ensure the fix doesn't introduce any regressions"\n<commentary>\nAfter bug fixes, use the tester agent to validate that existing tests still pass.\n</commentary>\n</example>
|
|
4
|
+
model: sonnet
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
You are a senior QA engineer specializing in comprehensive testing and quality assurance. Your expertise spans unit testing, integration testing, performance validation, and build process verification. You ensure code reliability through rigorous testing practices and detailed analysis.
|
|
8
|
+
|
|
9
|
+
**Core Responsibilities:**
|
|
10
|
+
|
|
11
|
+
1. **Test Execution & Validation**
|
|
12
|
+
- Run all relevant test suites (unit, integration, e2e as applicable)
|
|
13
|
+
- Execute tests using appropriate test runners (Jest, Mocha, pytest, etc.)
|
|
14
|
+
- Validate that all tests pass successfully
|
|
15
|
+
- Identify and report any failing tests with detailed error messages
|
|
16
|
+
- Check for flaky tests that may pass/fail intermittently
|
|
17
|
+
|
|
18
|
+
2. **Coverage Analysis**
|
|
19
|
+
- Generate and analyze code coverage reports
|
|
20
|
+
- Identify uncovered code paths and functions
|
|
21
|
+
- Ensure coverage meets project requirements (typically 80%+)
|
|
22
|
+
- Highlight critical areas lacking test coverage
|
|
23
|
+
- Suggest specific test cases to improve coverage
|
|
24
|
+
|
|
25
|
+
3. **Error Scenario Testing**
|
|
26
|
+
- Verify error handling mechanisms are properly tested
|
|
27
|
+
- Ensure edge cases are covered
|
|
28
|
+
- Validate exception handling and error messages
|
|
29
|
+
- Check for proper cleanup in error scenarios
|
|
30
|
+
- Test boundary conditions and invalid inputs
|
|
31
|
+
|
|
32
|
+
4. **Performance Validation**
|
|
33
|
+
- Run performance benchmarks where applicable
|
|
34
|
+
- Measure test execution time
|
|
35
|
+
- Identify slow-running tests that may need optimization
|
|
36
|
+
- Validate performance requirements are met
|
|
37
|
+
- Check for memory leaks or resource issues
|
|
38
|
+
|
|
39
|
+
5. **Build Process Verification**
|
|
40
|
+
- Ensure the build process completes successfully
|
|
41
|
+
- Validate all dependencies are properly resolved
|
|
42
|
+
- Check for build warnings or deprecation notices
|
|
43
|
+
- Verify production build configurations
|
|
44
|
+
- Test CI/CD pipeline compatibility
|
|
45
|
+
|
|
46
|
+
**Working Process:**
|
|
47
|
+
|
|
48
|
+
1. First, identify the testing scope based on recent changes or specific requirements
|
|
49
|
+
2. Run `flutter analyze` to identify syntax errors
|
|
50
|
+
3. Run the appropriate test suites using project-specific commands
|
|
51
|
+
4. Analyze test results, paying special attention to failures
|
|
52
|
+
5. Generate and review coverage reports
|
|
53
|
+
6. Validate build processes if relevant
|
|
54
|
+
7. Create a comprehensive summary report
|
|
55
|
+
|
|
56
|
+
**Output Format:**
|
|
57
|
+
|
|
58
|
+
Your summary report should include:
|
|
59
|
+
- **Test Results Overview**: Total tests run, passed, failed, skipped
|
|
60
|
+
- **Coverage Metrics**: Line coverage, branch coverage, function coverage percentages
|
|
61
|
+
- **Failed Tests**: Detailed information about any failures including error messages and stack traces
|
|
62
|
+
- **Performance Metrics**: Test execution time, slow tests identified
|
|
63
|
+
- **Build Status**: Success/failure status with any warnings
|
|
64
|
+
- **Critical Issues**: Any blocking issues that need immediate attention
|
|
65
|
+
- **Recommendations**: Actionable tasks to improve test quality and coverage
|
|
66
|
+
- **Next Steps**: Prioritized list of testing improvements
|
|
67
|
+
|
|
68
|
+
**Quality Standards:**
|
|
69
|
+
- Ensure all critical paths have test coverage
|
|
70
|
+
- Validate both happy path and error scenarios
|
|
71
|
+
- Check for proper test isolation (no test interdependencies)
|
|
72
|
+
- Verify tests are deterministic and reproducible
|
|
73
|
+
- Ensure test data cleanup after execution
|
|
74
|
+
|
|
75
|
+
**Tools & Commands:**
|
|
76
|
+
You should be familiar with common testing commands:
|
|
77
|
+
- `flutter analyze` and `flutter test` for Flutter projects
|
|
78
|
+
- `npm test` or `yarn test` for JavaScript/TypeScript projects
|
|
79
|
+
- `npm run test:coverage` for coverage reports
|
|
80
|
+
- `pytest` or `python -m unittest` for Python projects
|
|
81
|
+
- `go test` for Go projects
|
|
82
|
+
- `cargo test` for Rust projects
|
|
83
|
+
- Docker-based test execution when applicable
|
|
84
|
+
|
|
85
|
+
**Important Considerations:**
|
|
86
|
+
- Always run tests in a clean environment when possible
|
|
87
|
+
- Consider both unit and integration test results
|
|
88
|
+
- Pay attention to test execution order dependencies
|
|
89
|
+
- Validate that mocks and stubs are properly configured
|
|
90
|
+
- Ensure database migrations or seeds are applied for integration tests
|
|
91
|
+
- Check for proper environment variable configuration
|
|
92
|
+
- Never ignore failing tests just to pass the build
|
|
93
|
+
- Use file system (in markdown format) to hand over reports in `./plans/reports` directory to each other with this file name format: `NNN-from-agent-name-to-agent-name-task-name-report.md`.
|
|
94
|
+
|
|
95
|
+
When encountering issues, provide clear, actionable feedback on how to resolve them. Your goal is to ensure the codebase maintains high quality standards through comprehensive testing practices.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Debugging technical issues and providing solutions.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
**Reported Issues**:
|
|
6
|
+
$ARGUMENTS
|
|
7
|
+
|
|
8
|
+
Use the `debugger` subagent to find the root cause of the issues, then analyze and explain the reports to the user.
|
|
9
|
+
|
|
10
|
+
**IMPORTANT**: **Do not** implement the fix automatically.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze the codebase and create initial documentation
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Use `docs/` directory as the source of truth for documentation.
|
|
6
|
+
Use `docs-manager` agent to analyze the codebase and create initial documentation:
|
|
7
|
+
- `docs/project-overview-pdr.md`: Project overview and PDR (Product Development Requirements)
|
|
8
|
+
- `docs/codebase-summary.md`: Codebase summary
|
|
9
|
+
- `docs/codebase-structure-architecture-code-standards.md`: Codebase structure, architecture, and code standards
|
|
10
|
+
|
|
11
|
+
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze the codebase and update documentation
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Use `docs/` directory as the source of truth for documentation.
|
|
6
|
+
Use `docs-manager` agent to analyze the codebase and update documentation:
|
|
7
|
+
- `docs/project-overview-pdr.md`: Update project overview and PDR (Product Development Requirements)
|
|
8
|
+
- `docs/codebase-summary.md`: Update codebase summary
|
|
9
|
+
- `docs/codebase-structure-architecture-code-standards.md`: Update codebase structure, architecture, and code standards
|
|
10
|
+
|
|
11
|
+
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze Github Actions logs and fix issues
|
|
3
|
+
---
|
|
4
|
+
## Github Actions URL
|
|
5
|
+
$ARGUMENTS
|
|
6
|
+
|
|
7
|
+
Use the `planer-researcher` to read the github actions logs, analyze and find the root causes of the issues, then provide a detailed plan for implementing the fixes.
|
|
8
|
+
Then use proper developer agents to implement the plan.
|
|
@@ -0,0 +1,16 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Run test suite and fix issues
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
## Reported Issues:
|
|
6
|
+
<issue>
|
|
7
|
+
$ARGUMENTS
|
|
8
|
+
</issue>
|
|
9
|
+
|
|
10
|
+
## Workflow:
|
|
11
|
+
1. First use `tester` subagent to run the tests.
|
|
12
|
+
2. Then use `debugger` subagent to find the root cause of the issues.
|
|
13
|
+
3. Then use `planner-researcher` subagent to create a implementation plan with TODO tasks in `./plans` directory.
|
|
14
|
+
4. Then use `flutter-mobile-dev` subagent to implement the plan.
|
|
15
|
+
5. After finishing, delegate to `code-reviewer` agent to review code.
|
|
16
|
+
6. Repeat this process until all tests pass and no more errors are reported.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Analyze Github Actions logs and provide a plan to fix the issues
|
|
3
|
+
---
|
|
4
|
+
## Github Actions URL
|
|
5
|
+
$ARGUMENTS
|
|
6
|
+
|
|
7
|
+
Use the `planer-researcher` to read the github actions logs, analyze and find the root causes of the issues, then provide a detailed plan for implementing the fixes.
|
|
8
|
+
|
|
9
|
+
**Output:**
|
|
10
|
+
Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.
|
|
11
|
+
|
|
12
|
+
**IMPORTANT:** Ask the user for confirmation before implementing.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Research & create an implementation plan with 2 approaches
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
Use the `planner-researcher` subagent to plan for this task:
|
|
6
|
+
<task>
|
|
7
|
+
$ARGUMENTS
|
|
8
|
+
</task>
|
|
9
|
+
|
|
10
|
+
**Output:**
|
|
11
|
+
Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.
|
|
12
|
+
|
|
13
|
+
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Review recent changes and wrap up the work
|
|
3
|
+
---
|
|
4
|
+
Review my current branch and the most recent commits.
|
|
5
|
+
Provide a detailed summary of all changes, including what was modified, added, or removed.
|
|
6
|
+
Analyze the overall impact and quality of the changes.
|
|
7
|
+
|
|
8
|
+
**IMPORTANT**: **Do not** start implementing.
|
|
@@ -0,0 +1,136 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
# Telegram Notification Hook for Claude Code (Project-Specific)
|
|
4
|
+
# This hook sends a notification to Telegram when Claude finishes a task
|
|
5
|
+
|
|
6
|
+
set -euo pipefail
|
|
7
|
+
|
|
8
|
+
# Read JSON input from stdin
|
|
9
|
+
INPUT=$(cat)
|
|
10
|
+
|
|
11
|
+
# Extract relevant information from the hook input
|
|
12
|
+
HOOK_TYPE=$(echo "$INPUT" | jq -r '.hookType // "unknown"')
|
|
13
|
+
PROJECT_DIR=$(echo "$INPUT" | jq -r '.projectDir // ""')
|
|
14
|
+
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
|
|
15
|
+
SESSION_ID=$(echo "$INPUT" | jq -r '.sessionId // ""')
|
|
16
|
+
PROJECT_NAME=$(basename "$PROJECT_DIR")
|
|
17
|
+
|
|
18
|
+
# Configuration - these will be set via environment variables
|
|
19
|
+
TELEGRAM_BOT_TOKEN="${TELEGRAM_BOT_TOKEN:-}"
|
|
20
|
+
TELEGRAM_CHAT_ID="${TELEGRAM_CHAT_ID:-}"
|
|
21
|
+
|
|
22
|
+
# Validate required environment variables
|
|
23
|
+
if [[ -z "$TELEGRAM_BOT_TOKEN" ]]; then
|
|
24
|
+
echo "Error: TELEGRAM_BOT_TOKEN environment variable not set" >&2
|
|
25
|
+
exit 1
|
|
26
|
+
fi
|
|
27
|
+
|
|
28
|
+
if [[ -z "$TELEGRAM_CHAT_ID" ]]; then
|
|
29
|
+
echo "Error: TELEGRAM_CHAT_ID environment variable not set" >&2
|
|
30
|
+
exit 1
|
|
31
|
+
fi
|
|
32
|
+
|
|
33
|
+
# Function to send Telegram message
|
|
34
|
+
send_telegram_message() {
|
|
35
|
+
local message="$1"
|
|
36
|
+
local url="https://api.telegram.org/bot${TELEGRAM_BOT_TOKEN}/sendMessage"
|
|
37
|
+
|
|
38
|
+
# Escape special characters for JSON
|
|
39
|
+
local escaped_message=$(echo "$message" | jq -Rs .)
|
|
40
|
+
|
|
41
|
+
local payload=$(cat <<EOF
|
|
42
|
+
{
|
|
43
|
+
"chat_id": "${TELEGRAM_CHAT_ID}",
|
|
44
|
+
"text": ${escaped_message},
|
|
45
|
+
"parse_mode": "Markdown",
|
|
46
|
+
"disable_web_page_preview": true
|
|
47
|
+
}
|
|
48
|
+
EOF
|
|
49
|
+
)
|
|
50
|
+
|
|
51
|
+
curl -s -X POST \
|
|
52
|
+
-H "Content-Type: application/json" \
|
|
53
|
+
-d "$payload" \
|
|
54
|
+
"$url" > /dev/null
|
|
55
|
+
}
|
|
56
|
+
|
|
57
|
+
# Generate summary based on hook type
|
|
58
|
+
case "$HOOK_TYPE" in
|
|
59
|
+
"Stop")
|
|
60
|
+
# Extract tool usage summary
|
|
61
|
+
TOOLS_USED=$(echo "$INPUT" | jq -r '.toolsUsed[]?.tool // empty' | sort | uniq -c | sort -nr)
|
|
62
|
+
FILES_MODIFIED=$(echo "$INPUT" | jq -r '.toolsUsed[]? | select(.tool == "Edit" or .tool == "Write" or .tool == "MultiEdit") | .parameters.file_path // empty' | sort | uniq)
|
|
63
|
+
|
|
64
|
+
# Count operations
|
|
65
|
+
TOTAL_TOOLS=$(echo "$INPUT" | jq '.toolsUsed | length')
|
|
66
|
+
|
|
67
|
+
# Build summary message
|
|
68
|
+
MESSAGE="🚀 *DevPocket Task Completed*
|
|
69
|
+
|
|
70
|
+
📅 *Time:* ${TIMESTAMP}
|
|
71
|
+
📁 *Project:* ${PROJECT_NAME}
|
|
72
|
+
🔧 *Total Operations:* ${TOTAL_TOOLS}
|
|
73
|
+
🆔 *Session:* ${SESSION_ID:0:8}...
|
|
74
|
+
|
|
75
|
+
*Tools Used:*"
|
|
76
|
+
|
|
77
|
+
if [[ -n "$TOOLS_USED" ]]; then
|
|
78
|
+
MESSAGE="${MESSAGE}
|
|
79
|
+
\`\`\`
|
|
80
|
+
${TOOLS_USED}
|
|
81
|
+
\`\`\`"
|
|
82
|
+
else
|
|
83
|
+
MESSAGE="${MESSAGE}
|
|
84
|
+
None"
|
|
85
|
+
fi
|
|
86
|
+
|
|
87
|
+
if [[ -n "$FILES_MODIFIED" ]]; then
|
|
88
|
+
MESSAGE="${MESSAGE}
|
|
89
|
+
|
|
90
|
+
*Files Modified:*"
|
|
91
|
+
while IFS= read -r file; do
|
|
92
|
+
if [[ -n "$file" ]]; then
|
|
93
|
+
# Show relative path from project root
|
|
94
|
+
relative_file=$(echo "$file" | sed "s|^${PROJECT_DIR}/||")
|
|
95
|
+
MESSAGE="${MESSAGE}
|
|
96
|
+
• ${relative_file}"
|
|
97
|
+
fi
|
|
98
|
+
done <<< "$FILES_MODIFIED"
|
|
99
|
+
fi
|
|
100
|
+
|
|
101
|
+
MESSAGE="${MESSAGE}
|
|
102
|
+
|
|
103
|
+
📍 *Location:* \`${PROJECT_DIR}\`"
|
|
104
|
+
;;
|
|
105
|
+
|
|
106
|
+
"SubagentStop")
|
|
107
|
+
SUBAGENT_TYPE=$(echo "$INPUT" | jq -r '.subagentType // "unknown"')
|
|
108
|
+
MESSAGE="🤖 *DevPocket Subagent Completed*
|
|
109
|
+
|
|
110
|
+
📅 *Time:* ${TIMESTAMP}
|
|
111
|
+
📁 *Project:* ${PROJECT_NAME}
|
|
112
|
+
🔧 *Agent Type:* ${SUBAGENT_TYPE}
|
|
113
|
+
🆔 *Session:* ${SESSION_ID:0:8}...
|
|
114
|
+
|
|
115
|
+
Specialized agent completed its task.
|
|
116
|
+
|
|
117
|
+
📍 *Location:* \`${PROJECT_DIR}\`"
|
|
118
|
+
;;
|
|
119
|
+
|
|
120
|
+
*)
|
|
121
|
+
MESSAGE="📝 *DevPocket Code Event*
|
|
122
|
+
|
|
123
|
+
📅 *Time:* ${TIMESTAMP}
|
|
124
|
+
📁 *Project:* ${PROJECT_NAME}
|
|
125
|
+
📋 *Event:* ${HOOK_TYPE}
|
|
126
|
+
🆔 *Session:* ${SESSION_ID:0:8}...
|
|
127
|
+
|
|
128
|
+
📍 *Location:* \`${PROJECT_DIR}\`"
|
|
129
|
+
;;
|
|
130
|
+
esac
|
|
131
|
+
|
|
132
|
+
# Send the notification
|
|
133
|
+
send_telegram_message "$MESSAGE"
|
|
134
|
+
|
|
135
|
+
# Log the notification (optional)
|
|
136
|
+
echo "Telegram notification sent for $HOOK_TYPE event in project $PROJECT_NAME" >&2
|
|
@@ -0,0 +1,64 @@
|
|
|
1
|
+
#!/bin/bash
|
|
2
|
+
|
|
3
|
+
# Usage: ./send-discord.sh 'Your message here'
|
|
4
|
+
# Note: Remember to escape the string
|
|
5
|
+
|
|
6
|
+
# Load environment variables from .env file
|
|
7
|
+
if [[ -f .env ]]; then
|
|
8
|
+
echo "Loading .env file..."
|
|
9
|
+
set -a # automatically export all variables
|
|
10
|
+
source .env
|
|
11
|
+
set +a # turn off automatic export
|
|
12
|
+
echo "✅ Environment loaded, DISCORD_WEBHOOK_URL=$(echo ${DISCORD_WEBHOOK_URL:0:50}...)"
|
|
13
|
+
else
|
|
14
|
+
echo "Warning: .env file not found"
|
|
15
|
+
fi
|
|
16
|
+
|
|
17
|
+
message="$1"
|
|
18
|
+
|
|
19
|
+
if [[ -z "$DISCORD_WEBHOOK_URL" ]]; then
|
|
20
|
+
echo "⚠️ Discord notification skipped: DISCORD_WEBHOOK_URL not set"
|
|
21
|
+
exit 1
|
|
22
|
+
fi
|
|
23
|
+
|
|
24
|
+
# Prepare message for Discord (Discord markdown supports \n)
|
|
25
|
+
discord_message="$message"
|
|
26
|
+
|
|
27
|
+
# Discord embeds for richer formatting
|
|
28
|
+
payload=$(cat <<EOF
|
|
29
|
+
{
|
|
30
|
+
"embeds": [{
|
|
31
|
+
"title": "🤖 Claude Code Session Complete",
|
|
32
|
+
"description": "$discord_message",
|
|
33
|
+
"color": 5763719,
|
|
34
|
+
"timestamp": "$(date -u +%Y-%m-%dT%H:%M:%S.000Z)",
|
|
35
|
+
"footer": {
|
|
36
|
+
"text": "DevPocket API • $(basename "$(pwd)")"
|
|
37
|
+
},
|
|
38
|
+
"fields": [
|
|
39
|
+
{
|
|
40
|
+
"name": "⏰ Session Time",
|
|
41
|
+
"value": "$(date '+%H:%M:%S')",
|
|
42
|
+
"inline": true
|
|
43
|
+
},
|
|
44
|
+
{
|
|
45
|
+
"name": "📂 Project",
|
|
46
|
+
"value": "$(basename "$(pwd)")",
|
|
47
|
+
"inline": true
|
|
48
|
+
}
|
|
49
|
+
]
|
|
50
|
+
}]
|
|
51
|
+
}
|
|
52
|
+
EOF
|
|
53
|
+
)
|
|
54
|
+
|
|
55
|
+
curl -s -X POST "$DISCORD_WEBHOOK_URL" \
|
|
56
|
+
-H "Content-Type: application/json" \
|
|
57
|
+
-d "$payload" >/dev/null 2>&1
|
|
58
|
+
|
|
59
|
+
if [[ $? -eq 0 ]]; then
|
|
60
|
+
echo "✅ Discord notification sent"
|
|
61
|
+
else
|
|
62
|
+
echo "❌ Failed to send Discord notification"
|
|
63
|
+
exit 1
|
|
64
|
+
fi
|