Initial commit
This commit is contained in:
88
skills/github-issue-processing/SKILL.md
Normal file
88
skills/github-issue-processing/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
name: github-issue-processing
|
||||
description: Extract actionable information from GitHub issues including requirements, acceptance criteria, and technical constraints. Use when analyzing GitHub issues or preparing them for workflow execution.
|
||||
---
|
||||
|
||||
# GitHub Issue Processing
|
||||
|
||||
This skill provides patterns for extracting and structuring information from GitHub issues.
|
||||
|
||||
## Information Extraction Pattern
|
||||
|
||||
When processing a GitHub issue, extract:
|
||||
|
||||
### 1. Core Requirements
|
||||
|
||||
```markdown
|
||||
## Requirements
|
||||
- Primary objective
|
||||
- User stories or use cases
|
||||
- Expected behavior
|
||||
```
|
||||
|
||||
### 2. Technical Details
|
||||
|
||||
```markdown
|
||||
## Technical Context
|
||||
- Affected components/modules
|
||||
- Current behavior vs. desired behavior
|
||||
- Stack traces or error messages (if applicable)
|
||||
- Environment details
|
||||
```
|
||||
|
||||
### 3. Acceptance Criteria
|
||||
|
||||
```markdown
|
||||
## Acceptance Criteria
|
||||
- [ ] Criterion 1: Specific, testable condition
|
||||
- [ ] Criterion 2: Specific, testable condition
|
||||
- [ ] Criterion 3: Specific, testable condition
|
||||
```
|
||||
|
||||
### 4. Constraints
|
||||
|
||||
```markdown
|
||||
## Constraints
|
||||
- Performance requirements
|
||||
- Backward compatibility needs
|
||||
- Security considerations
|
||||
- Dependencies on other issues/PRs
|
||||
```
|
||||
|
||||
## Labels Interpretation
|
||||
|
||||
Common GitHub labels and their implications:
|
||||
|
||||
- **bug**: Fix existing functionality, requires root cause analysis
|
||||
- **enhancement**: Add new functionality, may need design review
|
||||
- **documentation**: Update docs, ensure accuracy and completeness
|
||||
- **breaking-change**: Impacts existing API, needs migration guide
|
||||
- **help-wanted**: Good for community contribution, provide clear guidance
|
||||
- **priority: high**: Address urgently, may need expedited review
|
||||
|
||||
## Issue Linking
|
||||
|
||||
Extract and track related issues:
|
||||
|
||||
```markdown
|
||||
## Related Issues
|
||||
- Blocks: #123, #456
|
||||
- Blocked by: #789
|
||||
- Related to: #321
|
||||
- Duplicate of: (if applicable)
|
||||
```
|
||||
|
||||
## Converting to PRP
|
||||
|
||||
Transform issue analysis into PRP format:
|
||||
|
||||
1. **Prompt**: Use issue title and description
|
||||
2. **Response**: Include analysis and proposed approach
|
||||
3. **Plan**: Break down into actionable steps with dependencies
|
||||
|
||||
## Integration Points
|
||||
|
||||
Works with:
|
||||
- `context-engineering-github-issue-analyzer` agent
|
||||
- `context-engineering-prp-generator` agent for issue → PRP conversion
|
||||
- `/initial-github-issue` command
|
||||
96
skills/prp-structure/SKILL.md
Normal file
96
skills/prp-structure/SKILL.md
Normal file
@@ -0,0 +1,96 @@
|
||||
---
|
||||
name: prp-structure
|
||||
description: Provides the standard structure and format for Prompt-Response-Plan (PRP) documents. Use when creating, formatting, or validating PRP documents for systematic problem-solving workflows.
|
||||
---
|
||||
|
||||
# PRP Structure Skill
|
||||
|
||||
This skill defines the standard structure for Prompt-Response-Plan (PRP) documents used in context engineering workflows.
|
||||
|
||||
## PRP Document Structure
|
||||
|
||||
A well-formed PRP contains three main sections:
|
||||
|
||||
### 1. Prompt Section
|
||||
|
||||
The initial problem statement or request that initiates the workflow:
|
||||
|
||||
```markdown
|
||||
## Prompt
|
||||
|
||||
[Clear, concise description of the problem or task]
|
||||
|
||||
### Context
|
||||
- Background information
|
||||
- Relevant constraints
|
||||
- Success criteria
|
||||
```
|
||||
|
||||
### 2. Response Section
|
||||
|
||||
Analysis and proposed approach:
|
||||
|
||||
```markdown
|
||||
## Response
|
||||
|
||||
### Problem Analysis
|
||||
- Key challenges identified
|
||||
- Dependencies and prerequisites
|
||||
- Risk factors
|
||||
|
||||
### Proposed Solution
|
||||
- High-level approach
|
||||
- Alternative approaches considered
|
||||
- Rationale for chosen approach
|
||||
```
|
||||
|
||||
### 3. Plan Section
|
||||
|
||||
Detailed execution plan with trackable steps:
|
||||
|
||||
```markdown
|
||||
## Plan
|
||||
|
||||
### Implementation Steps
|
||||
|
||||
1. [ ] Step 1: [Description]
|
||||
- Sub-tasks if needed
|
||||
- Expected outcome
|
||||
|
||||
2. [ ] Step 2: [Description]
|
||||
- Dependencies: Step 1
|
||||
- Expected outcome
|
||||
|
||||
3. [ ] Step 3: [Description]
|
||||
|
||||
### Testing Strategy
|
||||
- Unit tests
|
||||
- Integration tests
|
||||
- Acceptance criteria
|
||||
|
||||
### Rollback Plan
|
||||
- Contingency steps if issues arise
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Keep prompts focused**: One PRP per distinct problem
|
||||
- **Be specific in plans**: Each step should be actionable and measurable
|
||||
- **Track progress**: Use checkboxes to mark completed steps
|
||||
- **Document assumptions**: Make implicit knowledge explicit
|
||||
- **Include validation**: Define how success will be measured
|
||||
|
||||
## File Naming Convention
|
||||
|
||||
```
|
||||
prp-[description]-[timestamp].md
|
||||
```
|
||||
|
||||
Example: `prp-refactor-auth-module-2025-11-21.md`
|
||||
|
||||
## Integration with Agents
|
||||
|
||||
This structure works seamlessly with:
|
||||
- `context-engineering-prp-generator` agent (generates PRPs)
|
||||
- `context-engineering-executor` agent (executes plans)
|
||||
- `context-engineering-orchestrator` agent (coordinates workflows)
|
||||
Reference in New Issue
Block a user