Add new commands, skills, and agents; remove token loading script
- Add groom, plan-issues, and roadmap commands - Add skills for backlog-grooming, forgejo, issue-writing, roadmap-planning - Add agents directory structure - Remove load-forgejo-token.sh and SessionStart hook (using fj auth instead) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
This commit is contained in:
34
agents/product-manager/AGENT.md
Normal file
34
agents/product-manager/AGENT.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# Product Manager Agent
|
||||
|
||||
Specialized agent for backlog management and roadmap planning.
|
||||
|
||||
## Skills
|
||||
|
||||
- forgejo
|
||||
- issue-writing
|
||||
- backlog-grooming
|
||||
- roadmap-planning
|
||||
|
||||
## Capabilities
|
||||
|
||||
This agent can:
|
||||
- Review and improve existing issues
|
||||
- Create new well-structured issues
|
||||
- Analyze the backlog for gaps and priorities
|
||||
- Plan feature breakdowns
|
||||
- Maintain roadmap clarity
|
||||
|
||||
## When to Use
|
||||
|
||||
Spawn this agent for:
|
||||
- Batch operations on multiple issues
|
||||
- Comprehensive backlog reviews
|
||||
- Feature planning that requires codebase exploration
|
||||
- Complex issue creation with dependencies
|
||||
|
||||
## Behavior
|
||||
|
||||
- Always fetches current issue state before making changes
|
||||
- Asks for approval before creating or modifying issues
|
||||
- Provides clear summaries of actions taken
|
||||
- Uses the fj CLI for all Forgejo operations
|
||||
31
commands/groom.md
Normal file
31
commands/groom.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
description: Groom and improve issues. Without argument, reviews all open issues. With argument, grooms specific issue.
|
||||
argument-hint: [issue-number]
|
||||
---
|
||||
|
||||
# Groom Issues
|
||||
|
||||
Use the backlog-grooming and issue-writing skills.
|
||||
|
||||
## If issue number provided ($1):
|
||||
|
||||
1. **Fetch the issue**: `fj issue view $1`
|
||||
2. **Evaluate** against grooming checklist
|
||||
3. **Suggest improvements** for:
|
||||
- Title clarity
|
||||
- Description completeness
|
||||
- Acceptance criteria quality
|
||||
- Scope definition
|
||||
4. **Ask user** if they want to apply changes
|
||||
5. **Update issue** if approved: `fj issue edit $1 --body "..."`
|
||||
|
||||
## If no argument (groom all):
|
||||
|
||||
1. **List open issues**: `fj issue search -s open`
|
||||
2. **Review each** against grooming checklist
|
||||
3. **Categorize**:
|
||||
- Ready: Well-defined, can start work
|
||||
- Needs work: Missing info or unclear
|
||||
- Stale: No longer relevant
|
||||
4. **Present summary** table
|
||||
5. **Offer to improve** issues that need work
|
||||
34
commands/plan-issues.md
Normal file
34
commands/plan-issues.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
description: Plan and create issues for a feature or improvement. Breaks down work into well-structured issues.
|
||||
argument-hint: <feature-description>
|
||||
---
|
||||
|
||||
# Plan Feature: $1
|
||||
|
||||
Use the roadmap-planning, issue-writing, and forgejo skills.
|
||||
|
||||
1. **Understand the feature**: Analyze what "$1" involves
|
||||
2. **Explore the codebase** if needed to understand context
|
||||
3. **Break down** into discrete, actionable issues:
|
||||
- Each issue should be independently completable
|
||||
- Clear dependencies between issues
|
||||
- Appropriate scope (not too big, not too small)
|
||||
|
||||
4. **Present the plan**:
|
||||
```
|
||||
## Proposed Issues for: $1
|
||||
|
||||
1. [Title] - Brief description
|
||||
Dependencies: none
|
||||
|
||||
2. [Title] - Brief description
|
||||
Dependencies: #1
|
||||
|
||||
3. [Title] - Brief description
|
||||
Dependencies: #1, #2
|
||||
```
|
||||
|
||||
5. **Ask for approval** before creating issues
|
||||
6. **Create issues** in order using `fj issue create`
|
||||
7. **Update dependencies** with actual issue numbers after creation
|
||||
8. **Present summary** with links to created issues
|
||||
31
commands/roadmap.md
Normal file
31
commands/roadmap.md
Normal file
@@ -0,0 +1,31 @@
|
||||
---
|
||||
description: View current issues as a roadmap. Shows open issues organized by status and dependencies.
|
||||
---
|
||||
|
||||
# Roadmap View
|
||||
|
||||
Use the forgejo skill.
|
||||
|
||||
1. **Fetch all open issues**: `fj issue search -s open`
|
||||
2. **Analyze dependencies** from issue descriptions
|
||||
3. **Categorize issues**:
|
||||
- Blocked: Waiting on other issues
|
||||
- Ready: No blockers, can start
|
||||
- In Progress: Has assignee or WIP label
|
||||
4. **Present roadmap** as organized list:
|
||||
|
||||
```
|
||||
## Ready to Start
|
||||
- #5: Add user authentication
|
||||
- #8: Create dashboard layout
|
||||
|
||||
## In Progress
|
||||
- #3: Setup database schema
|
||||
|
||||
## Blocked
|
||||
- #7: User profile page (blocked by #5)
|
||||
- #9: Admin dashboard (blocked by #3, #8)
|
||||
```
|
||||
|
||||
5. **Highlight** any issues that seem stale or unclear
|
||||
6. **Suggest** next actions based on the roadmap state
|
||||
@@ -1,9 +0,0 @@
|
||||
#!/bin/bash
|
||||
# Load Forgejo token from macOS Keychain into Claude Code session
|
||||
if [ -n "$CLAUDE_ENV_FILE" ]; then
|
||||
TOKEN=$(security find-generic-password -a "$USER" -s "forgejo-token" -w 2>/dev/null)
|
||||
if [ -n "$TOKEN" ]; then
|
||||
echo "export FORGEJO_TOKEN=\"$TOKEN\"" >> "$CLAUDE_ENV_FILE"
|
||||
fi
|
||||
fi
|
||||
exit 0
|
||||
@@ -8,16 +8,6 @@
|
||||
"gopls-lsp@claude-plugins-official": true
|
||||
},
|
||||
"hooks": {
|
||||
"SessionStart": [
|
||||
{
|
||||
"hooks": [
|
||||
{
|
||||
"type": "command",
|
||||
"command": "~/.claude/scripts/load-forgejo-token.sh"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"PreToolUse": [
|
||||
{
|
||||
"matcher": "Bash(git commit:*)",
|
||||
|
||||
83
skills/backlog-grooming/SKILL.md
Normal file
83
skills/backlog-grooming/SKILL.md
Normal file
@@ -0,0 +1,83 @@
|
||||
# Backlog Grooming
|
||||
|
||||
How to review and improve existing issues.
|
||||
|
||||
## Grooming Checklist
|
||||
|
||||
For each issue, verify:
|
||||
|
||||
### 1. Title Clarity
|
||||
- [ ] Starts with action verb
|
||||
- [ ] Specific and descriptive
|
||||
- [ ] Understandable without reading description
|
||||
|
||||
### 2. Description Quality
|
||||
- [ ] Has clear summary
|
||||
- [ ] Explains the "why"
|
||||
- [ ] Provides enough context
|
||||
|
||||
### 3. Acceptance Criteria
|
||||
- [ ] Criteria exist
|
||||
- [ ] Each criterion is testable
|
||||
- [ ] Criteria are specific (not vague)
|
||||
- [ ] Complete set (nothing missing)
|
||||
|
||||
### 4. Scope
|
||||
- [ ] Not too broad (can complete in reasonable time)
|
||||
- [ ] Not too narrow (meaningful unit of work)
|
||||
- [ ] Clear boundaries (what's included/excluded)
|
||||
|
||||
### 5. Dependencies
|
||||
- [ ] Dependencies identified
|
||||
- [ ] No circular dependencies
|
||||
- [ ] Blocking issues are tracked
|
||||
|
||||
### 6. Labels
|
||||
- [ ] Type label (bug/feature/etc)
|
||||
- [ ] Priority if applicable
|
||||
- [ ] Component labels if applicable
|
||||
|
||||
## Common Issues to Fix
|
||||
|
||||
### Vague Titles
|
||||
- Bad: "Fix bug"
|
||||
- Good: "Fix login form validation on empty email"
|
||||
|
||||
### Missing Acceptance Criteria
|
||||
Add specific, testable criteria based on the description.
|
||||
|
||||
### Scope Creep
|
||||
If issue covers multiple features, split into separate issues.
|
||||
|
||||
### Stale Issues
|
||||
- Close if no longer relevant
|
||||
- Update if context has changed
|
||||
- Add "needs-triage" label if unclear
|
||||
|
||||
### Duplicate Issues
|
||||
- Close duplicate with reference to original
|
||||
- Merge relevant details into original
|
||||
|
||||
## Grooming Workflow
|
||||
|
||||
1. **Fetch open issues**: `fj issue search -s open`
|
||||
2. **Review each issue** against checklist
|
||||
3. **Improve or flag** issues that need work
|
||||
4. **Update issue** with improvements: `fj issue edit <n> --body "..."`
|
||||
5. **Add labels** as needed: `fj issue label add <n> <label>`
|
||||
|
||||
## Questions to Ask
|
||||
|
||||
When grooming, consider:
|
||||
- "Could a developer start work on this today?"
|
||||
- "How will we know when this is done?"
|
||||
- "Is the scope clear?"
|
||||
- "Are dependencies explicit?"
|
||||
|
||||
## Batch Grooming
|
||||
|
||||
When grooming multiple issues:
|
||||
1. List all open issues
|
||||
2. Categorize by quality (ready, needs-work, stale)
|
||||
3. Focus on "needs-work" issues
|
||||
4. Present summary of changes made
|
||||
88
skills/forgejo/SKILL.md
Normal file
88
skills/forgejo/SKILL.md
Normal file
@@ -0,0 +1,88 @@
|
||||
# Forgejo CLI (fj)
|
||||
|
||||
Command-line interface for interacting with Forgejo repositories.
|
||||
|
||||
## Authentication
|
||||
|
||||
The `fj` CLI authenticates via `fj auth login`. Credentials are stored locally by fj.
|
||||
|
||||
## Repository Detection
|
||||
|
||||
`fj` automatically detects the repository from git remotes when run inside a git repository.
|
||||
|
||||
## Common Commands
|
||||
|
||||
### Issues
|
||||
|
||||
```bash
|
||||
# List issues
|
||||
fj issue search -s open # Open issues
|
||||
fj issue search -s closed # Closed issues
|
||||
fj issue search # All issues
|
||||
|
||||
# View issue details
|
||||
fj issue view <number> # Full issue details
|
||||
|
||||
# Create issue
|
||||
fj issue create "<title>" --body "<body>"
|
||||
|
||||
# Edit issue
|
||||
fj issue edit <number> --title "<new-title>"
|
||||
fj issue edit <number> --body "<new-body>"
|
||||
|
||||
# Close/reopen
|
||||
fj issue close <number>
|
||||
fj issue reopen <number>
|
||||
|
||||
# Labels
|
||||
fj issue label add <number> <label>
|
||||
fj issue label remove <number> <label>
|
||||
```
|
||||
|
||||
### Pull Requests
|
||||
|
||||
```bash
|
||||
# List PRs
|
||||
fj pr search -s open # Open PRs
|
||||
fj pr search -s closed # Closed/merged PRs
|
||||
|
||||
# View PR
|
||||
fj pr view <number> # PR details
|
||||
fj pr view <number> diff # PR diff
|
||||
|
||||
# Create PR
|
||||
fj pr create "<title>" --body "<body>"
|
||||
fj pr create "<title>" --body "Closes #<issue>"
|
||||
|
||||
# PR status
|
||||
fj pr status <number> # CI status, reviews
|
||||
|
||||
# Review
|
||||
fj pr review <number> --approve
|
||||
fj pr review <number> --request-changes --body "<feedback>"
|
||||
fj pr review <number> --comment --body "<comment>"
|
||||
|
||||
# Merge
|
||||
fj pr merge <number>
|
||||
fj pr merge <number> --squash
|
||||
```
|
||||
|
||||
### Repository
|
||||
|
||||
```bash
|
||||
fj repo view # Repository info
|
||||
fj repo clone <owner>/<repo> # Clone repository
|
||||
```
|
||||
|
||||
## Output Formatting
|
||||
|
||||
Most commands support `--output` flag:
|
||||
- `--output json` - Machine-readable JSON
|
||||
- `--output table` - Tabular format (default for lists)
|
||||
- `--output simple` - Plain text
|
||||
|
||||
## Tips
|
||||
|
||||
- Always verify you're in the correct repository before running commands
|
||||
- Use `fj issue search` to find issue numbers before viewing/editing
|
||||
- Reference issues in PR bodies with `Closes #N` for auto-linking
|
||||
105
skills/issue-writing/SKILL.md
Normal file
105
skills/issue-writing/SKILL.md
Normal file
@@ -0,0 +1,105 @@
|
||||
# Issue Writing
|
||||
|
||||
How to write clear, actionable issues.
|
||||
|
||||
## Issue Structure
|
||||
|
||||
### Title
|
||||
- Start with action verb: "Add", "Fix", "Update", "Remove", "Refactor"
|
||||
- Be specific: "Add user authentication" not "Auth stuff"
|
||||
- Keep under 60 characters when possible
|
||||
|
||||
### Description
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
One paragraph explaining what and why.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Specific, testable requirement
|
||||
- [ ] Another requirement
|
||||
- [ ] User can verify this works
|
||||
|
||||
## Context
|
||||
Additional background, links, or references.
|
||||
|
||||
## Technical Notes (optional)
|
||||
Implementation hints or constraints.
|
||||
```
|
||||
|
||||
## Writing Acceptance Criteria
|
||||
|
||||
Good criteria are:
|
||||
- **Specific**: "User sees error message" not "Handle errors"
|
||||
- **Testable**: Can verify pass/fail
|
||||
- **User-focused**: What the user experiences
|
||||
- **Independent**: Each stands alone
|
||||
|
||||
Examples:
|
||||
```markdown
|
||||
- [ ] Login form validates email format before submission
|
||||
- [ ] Invalid credentials show "Invalid email or password" message
|
||||
- [ ] Successful login redirects to dashboard
|
||||
- [ ] Session persists across browser refresh
|
||||
```
|
||||
|
||||
## Issue Types
|
||||
|
||||
### Bug Report
|
||||
```markdown
|
||||
## Summary
|
||||
Description of the bug.
|
||||
|
||||
## Steps to Reproduce
|
||||
1. Go to...
|
||||
2. Click...
|
||||
3. Observe...
|
||||
|
||||
## Expected Behavior
|
||||
What should happen.
|
||||
|
||||
## Actual Behavior
|
||||
What happens instead.
|
||||
|
||||
## Environment
|
||||
- Browser/OS/Version
|
||||
```
|
||||
|
||||
### Feature Request
|
||||
```markdown
|
||||
## Summary
|
||||
What feature and why it's valuable.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] ...
|
||||
|
||||
## User Story (optional)
|
||||
As a [role], I want [capability] so that [benefit].
|
||||
```
|
||||
|
||||
### Technical Task
|
||||
```markdown
|
||||
## Summary
|
||||
What technical work needs to be done.
|
||||
|
||||
## Scope
|
||||
- Include: ...
|
||||
- Exclude: ...
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] ...
|
||||
```
|
||||
|
||||
## Labels
|
||||
|
||||
Use labels to categorize:
|
||||
- `bug`, `feature`, `enhancement`, `refactor`
|
||||
- `priority/high`, `priority/low`
|
||||
- Component labels specific to project
|
||||
|
||||
## Dependencies
|
||||
|
||||
Reference related issues:
|
||||
- "Depends on #N" - Must complete first
|
||||
- "Blocks #N" - This blocks another
|
||||
- "Related to #N" - Informational link
|
||||
118
skills/roadmap-planning/SKILL.md
Normal file
118
skills/roadmap-planning/SKILL.md
Normal file
@@ -0,0 +1,118 @@
|
||||
# Roadmap Planning
|
||||
|
||||
How to plan features and create issues for implementation.
|
||||
|
||||
## Planning Process
|
||||
|
||||
### 1. Understand the Goal
|
||||
- What capability or improvement is needed?
|
||||
- Who benefits and how?
|
||||
- What's the success criteria?
|
||||
|
||||
### 2. Break Down the Work
|
||||
- Identify distinct components
|
||||
- Define boundaries between pieces
|
||||
- Aim for issues that are:
|
||||
- Completable in 1-3 focused sessions
|
||||
- Independently testable
|
||||
- Clear in scope
|
||||
|
||||
### 3. Identify Dependencies
|
||||
- Which pieces must come first?
|
||||
- What can be parallelized?
|
||||
- Are there external blockers?
|
||||
|
||||
### 4. Create Issues
|
||||
- Follow issue-writing patterns
|
||||
- Reference dependencies explicitly
|
||||
- Use consistent labeling
|
||||
|
||||
## Breaking Down Features
|
||||
|
||||
### By Layer
|
||||
```
|
||||
Feature: User Authentication
|
||||
├── Data layer: User model, password hashing
|
||||
├── API layer: Login/logout endpoints
|
||||
├── UI layer: Login form, session display
|
||||
└── Integration: Connect all layers
|
||||
```
|
||||
|
||||
### By User Story
|
||||
```
|
||||
Feature: Shopping Cart
|
||||
├── Add item to cart
|
||||
├── View cart contents
|
||||
├── Update quantities
|
||||
├── Remove items
|
||||
└── Proceed to checkout
|
||||
```
|
||||
|
||||
### By Technical Component
|
||||
```
|
||||
Feature: Real-time Updates
|
||||
├── WebSocket server setup
|
||||
├── Client connection handling
|
||||
├── Message protocol
|
||||
├── Reconnection logic
|
||||
└── Integration tests
|
||||
```
|
||||
|
||||
## Issue Ordering
|
||||
|
||||
### Dependency Chain
|
||||
Create issues in implementation order:
|
||||
1. Foundation (models, types, interfaces)
|
||||
2. Core logic (business rules)
|
||||
3. Integration (connecting pieces)
|
||||
4. Polish (error handling, edge cases)
|
||||
|
||||
### Reference Pattern
|
||||
In issue descriptions:
|
||||
```markdown
|
||||
## Dependencies
|
||||
- Depends on #12 (user model)
|
||||
- Depends on #13 (API setup)
|
||||
```
|
||||
|
||||
## Creating Issues with fj
|
||||
|
||||
### Single Issue
|
||||
```bash
|
||||
fj issue create "Add user authentication endpoint" --body "$(cat <<'EOF'
|
||||
## Summary
|
||||
Create POST /api/auth/login endpoint for user authentication.
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] Endpoint accepts email and password
|
||||
- [ ] Returns JWT token on success
|
||||
- [ ] Returns 401 on invalid credentials
|
||||
- [ ] Rate limits login attempts
|
||||
|
||||
## Dependencies
|
||||
- Depends on #5 (user model)
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
### Batch Creation
|
||||
When creating multiple related issues:
|
||||
1. Plan all issues first
|
||||
2. Create in dependency order
|
||||
3. Update earlier issues with forward references
|
||||
|
||||
## Roadmap View
|
||||
|
||||
To see current roadmap:
|
||||
1. List open issues: `fj issue search -s open`
|
||||
2. Group by labels/milestones
|
||||
3. Identify blocked vs ready issues
|
||||
4. Prioritize based on dependencies and value
|
||||
|
||||
## Planning Questions
|
||||
|
||||
Before creating issues, answer:
|
||||
- "What's the minimum viable version?"
|
||||
- "What can we defer?"
|
||||
- "What are the riskiest parts?"
|
||||
- "How will we validate each piece?"
|
||||
Reference in New Issue
Block a user