bugsink mcp and claude subagents - documentation and test fixes
All checks were successful
Deploy to Test Environment / deploy-to-test (push) Successful in 19m11s
All checks were successful
Deploy to Test Environment / deploy-to-test (push) Successful in 19m11s
This commit is contained in:
@@ -32,6 +32,7 @@ The documenter subagent understands:
|
||||
### Example Requests
|
||||
|
||||
**API Documentation:**
|
||||
|
||||
```
|
||||
"Use documenter to create API documentation for the shopping
|
||||
list endpoints. Include request/response schemas, authentication
|
||||
@@ -39,6 +40,7 @@ requirements, and example curl commands."
|
||||
```
|
||||
|
||||
**Feature Guide:**
|
||||
|
||||
```
|
||||
"Use documenter to write a user guide for the price watchlist
|
||||
feature. Explain how to add items, set price alerts, and view
|
||||
@@ -46,6 +48,7 @@ price history."
|
||||
```
|
||||
|
||||
**Troubleshooting Guide:**
|
||||
|
||||
```
|
||||
"Use documenter to create a troubleshooting guide for common
|
||||
flyer upload issues, including file format errors, size limits,
|
||||
@@ -56,7 +59,7 @@ and processing failures."
|
||||
|
||||
#### API Documentation Format
|
||||
|
||||
```markdown
|
||||
````markdown
|
||||
### [METHOD] /api/endpoint
|
||||
|
||||
**Description**: Brief purpose of the endpoint
|
||||
@@ -64,6 +67,7 @@ and processing failures."
|
||||
**Authentication**: Required (Bearer token)
|
||||
|
||||
**Request**:
|
||||
|
||||
- Headers: `Content-Type: application/json`, `Authorization: Bearer {token}`
|
||||
- Body:
|
||||
```json
|
||||
@@ -72,8 +76,10 @@ and processing failures."
|
||||
"optional_field": "number (optional) - Description"
|
||||
}
|
||||
```
|
||||
````
|
||||
|
||||
**Response**:
|
||||
|
||||
- Success (200):
|
||||
```json
|
||||
{
|
||||
@@ -93,13 +99,15 @@ and processing failures."
|
||||
```
|
||||
|
||||
**Example**:
|
||||
|
||||
```bash
|
||||
curl -X POST https://api.example.com/api/endpoint \
|
||||
-H "Authorization: Bearer $TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"field": "value"}'
|
||||
```
|
||||
```
|
||||
|
||||
````
|
||||
|
||||
## The describer-for-ai Subagent
|
||||
|
||||
@@ -163,11 +171,12 @@ Technical details, code examples, configuration.
|
||||
## Related ADRs
|
||||
|
||||
- [ADR-XXX](./XXXX-title.md) - Related decision
|
||||
```
|
||||
````
|
||||
|
||||
### Example Requests
|
||||
|
||||
**Creating an ADR:**
|
||||
|
||||
```
|
||||
"Use describer-for-ai to create an ADR for adding websocket
|
||||
support for real-time price alerts. Include the technical
|
||||
@@ -175,6 +184,7 @@ approach, alternatives considered, and implementation details."
|
||||
```
|
||||
|
||||
**CLAUDE.md Update:**
|
||||
|
||||
```
|
||||
"Use describer-for-ai to update CLAUDE.md with the new
|
||||
authentication flow and any new patterns developers should
|
||||
@@ -182,6 +192,7 @@ be aware of."
|
||||
```
|
||||
|
||||
**Technical Overview:**
|
||||
|
||||
```
|
||||
"Use describer-for-ai to create a technical overview of the
|
||||
caching layer for future AI context, including how Redis is
|
||||
@@ -213,6 +224,7 @@ The planner subagent understands:
|
||||
### Example Requests
|
||||
|
||||
**Feature Breakdown:**
|
||||
|
||||
```
|
||||
"Use planner to break down the 'store comparison' feature
|
||||
into implementable tasks. Include frontend, backend, and
|
||||
@@ -220,6 +232,7 @@ database work. Identify dependencies between tasks."
|
||||
```
|
||||
|
||||
**Roadmap Planning:**
|
||||
|
||||
```
|
||||
"Use planner to create a roadmap for the Q2 features:
|
||||
recipe integration, mobile app preparation, and store
|
||||
@@ -227,6 +240,7 @@ notifications. Identify what can be parallelized."
|
||||
```
|
||||
|
||||
**Scope Assessment:**
|
||||
|
||||
```
|
||||
"Use planner to assess the scope of adding multi-language
|
||||
support. What systems would need to change? What's the
|
||||
@@ -239,11 +253,13 @@ minimum viable implementation?"
|
||||
# Feature: [Feature Name]
|
||||
|
||||
## Overview
|
||||
|
||||
Brief description of the feature and its value.
|
||||
|
||||
## Tasks
|
||||
|
||||
### Phase 1: Foundation
|
||||
|
||||
1. **[Task Name]** (S/M/L)
|
||||
- Description
|
||||
- Files: `path/to/file.ts`
|
||||
@@ -257,20 +273,25 @@ Brief description of the feature and its value.
|
||||
- Acceptance: What "done" looks like
|
||||
|
||||
### Phase 2: Core Implementation
|
||||
|
||||
...
|
||||
|
||||
### Phase 3: Polish & Testing
|
||||
|
||||
...
|
||||
|
||||
## Dependencies
|
||||
|
||||
- External: Third-party services, APIs
|
||||
- Internal: Other features that must be complete first
|
||||
|
||||
## Risks
|
||||
|
||||
- Risk 1: Mitigation strategy
|
||||
- Risk 2: Mitigation strategy
|
||||
|
||||
## Estimates
|
||||
|
||||
- Phase 1: X days
|
||||
- Phase 2: Y days
|
||||
- Phase 3: Z days
|
||||
@@ -302,6 +323,7 @@ The product-owner subagent understands:
|
||||
### Example Requests
|
||||
|
||||
**User Story Writing:**
|
||||
|
||||
```
|
||||
"Use product-owner to write user stories for the meal planning
|
||||
feature. Consider different user personas: budget shoppers,
|
||||
@@ -309,6 +331,7 @@ health-conscious users, and busy families."
|
||||
```
|
||||
|
||||
**Acceptance Criteria:**
|
||||
|
||||
```
|
||||
"Use product-owner to define acceptance criteria for the price
|
||||
alert feature. What conditions must be met for this feature
|
||||
@@ -316,6 +339,7 @@ to be considered complete?"
|
||||
```
|
||||
|
||||
**Prioritization:**
|
||||
|
||||
```
|
||||
"Use product-owner to prioritize these feature requests based
|
||||
on user value and development effort:
|
||||
@@ -341,11 +365,13 @@ on user value and development effort:
|
||||
**Then** [expected outcome]
|
||||
|
||||
### Additional Notes
|
||||
|
||||
- Edge cases to consider
|
||||
- Related features
|
||||
- Out of scope items
|
||||
|
||||
### Technical Notes
|
||||
|
||||
- API endpoints needed
|
||||
- Database changes
|
||||
- Third-party integrations
|
||||
@@ -378,6 +404,7 @@ Documentation should be updated alongside code changes. The `describer-for-ai` s
|
||||
### 2. Use Consistent Terminology
|
||||
|
||||
Refer to entities and concepts consistently:
|
||||
|
||||
- "Flyer" not "Ad" or "Circular"
|
||||
- "Store" not "Retailer" or "Shop"
|
||||
- "Deal" not "Offer" or "Sale"
|
||||
@@ -385,6 +412,7 @@ Refer to entities and concepts consistently:
|
||||
### 3. Include Examples
|
||||
|
||||
All documentation should include concrete examples:
|
||||
|
||||
- API docs: Include curl commands and JSON payloads
|
||||
- User guides: Include screenshots or step-by-step instructions
|
||||
- Technical docs: Include code snippets
|
||||
@@ -392,6 +420,7 @@ All documentation should include concrete examples:
|
||||
### 4. Cross-Reference Related Documentation
|
||||
|
||||
Use relative links to connect related documentation:
|
||||
|
||||
```markdown
|
||||
See [Testing Guide](../TESTING.md) for test execution details.
|
||||
```
|
||||
@@ -399,6 +428,7 @@ See [Testing Guide](../TESTING.md) for test execution details.
|
||||
### 5. Date and Version Documentation
|
||||
|
||||
Include dates on documentation that may become stale:
|
||||
|
||||
```markdown
|
||||
**Last Updated**: 2026-01-21
|
||||
**Applies to**: v0.12.x
|
||||
|
||||
Reference in New Issue
Block a user