zhongwei/gh-rasmusgodske-dev-agent-workflow-project-roles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:49:43 +08:00
commit 720714fdad
23 changed files with 4002 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

148
commands/linear/review-project.md Normal file
View File

@@ -0,0 +1,148 @@
# Review Linear Project
Get a comprehensive briefing on a Linear project's status, progress, and remaining work.
## Usage
`/linear/review-project <project-name-or-id>`
## How Your Role Affects the Review
Your active role determines your focus:
- **Tech Lead**: Architecture, project health, technical decisions, task breakdown quality
- **Backend Engineer**: Backend implementation quality, patterns used, technical debt
- **Frontend Engineer**: Frontend implementation, component quality, UX decisions
- **Fullstack Engineer**: Integration between layers, end-to-end coherence
- **No role active**: General overview of project status
## Workflow
### 1. Load Complete Project Context
Gather all available information:
**Project Details:**
- Use `mcp__linear-server__get_project` to fetch project information
- Read the full project description and documentation
- **Extract branch information** from the description (look for "## Branch" section)
**All Issues (Complete History):**
- Use `mcp__linear-server__list_issues` with:
- Project filter
- `includeArchived: true`
- NO status filter (get everything: Done, In Progress, To Do, Canceled, etc.)
- Sort by `createdAt` to understand chronological order
**Issue Comments (Implementation Details):**
- Use `mcp__linear-server__list_comments` for issues marked as "Done"
- Look for implementation summaries, concerns, and technical decisions
- Identify patterns in the implementation approach
**Related Documentation:**
- Use `mcp__linear-server__list_documents` filtered by project
- Read key documents that provide additional context
### 2. Analyze the Project
Synthesize all information to understand:
- **Overall goal and purpose** of the feature
- **Technical approach** and architecture decisions
- **Progress made** - what's been completed and how
- **Current state** - what's in progress, blocked, or waiting
- **Remaining work** - what still needs to be done
- **Recent activity** - what was worked on most recently
### 3. Provide Comprehensive Briefing
Present your findings in this structured format:
```markdown
# Project Review: [Project Name]
**🌿 Branch:** `[branch-name]` (or "Not specified" if missing)
## Overview
[2-3 paragraphs explaining what this feature is, why it exists, and what problem it solves. Include the technical approach and key architectural decisions.]
## Current Status
**Progress:** [X] of [Y] issues complete ([Z]%)
**State:** [e.g., "Active development" / "Blocked" / "Nearly complete" / "Stalled"]
**Last activity:** [Date and brief description of most recent work]
## What Has Been Done ✅
[List completed work with brief descriptions. Group related items if it makes sense.]
1. **[Completed Feature/Task]**
- Implementation: [Brief technical summary from comments]
- Files involved: [Key files mentioned]
- Notes: [Any concerns or decisions mentioned in implementation]
2. **[Next completed item]**
- ...
## What Needs To Be Done 📋
[List remaining work in priority/logical order]
1. **[Task name]** (Status: [To Do/In Progress/Blocked])
- Purpose: [What this accomplishes]
- Depends on: [Any dependencies, if mentioned]
2. **[Next task]**
- ...
## Last Thing We Worked On 🔄
**Issue:** [Issue title and ID]
**Status:** [Current status]
**What was done:**
[Detailed explanation based on comments and status]
**What's next:**
[Logical next step based on project state]
## Technical Considerations
[Highlight any important technical details, concerns raised in comments, patterns established, or decisions made that someone continuing this work should know about. Focus on aspects relevant to your role.]
## Recommendation
[Your honest assessment: Is this project on track? Are there concerns? What should be prioritized next? Provide perspective based on your role's focus.]
```
### 4. Offer Next Steps
After presenting the review, ask:
> "Would you like me to:
> - Work on a specific issue? (Use `/linear/work-on-issue [issue-id]`)
> - Dive deeper into a specific implementation?
> - Update the project plan based on what I found?"
## Guidelines
- **Be thorough** - read all issues and comments to understand the full picture
- **Be honest** - if something seems incomplete or concerning, mention it
- **Provide context** - explain technical decisions and patterns
- **Show chronology** - help understand the development timeline
- **Identify blockers** - call out anything that might prevent progress
- **Be concise** - provide details but keep it readable
- **Think critically** - analyze what's been done, not just list it
- **Apply your role's lens** - focus on aspects relevant to your expertise
- **Branch handling** - if no branch is specified, note "Branch: Not specified" and suggest updating the project description
## Example Opening
Good opening for your review:
```
I've reviewed the Linear project "[Name]" including all 15 issues (8 completed, 3 in progress, 4 pending) and their implementation comments. Here's a comprehensive briefing on where this project stands:
```
## Notes
- This is a **read-only, analytical command** - no code changes
- Focus on understanding and communicating project state
- Use implementation comments to understand what was actually built, not just planned
- Identify the "story" of the project - how it evolved and where it's heading
- Your active role affects which aspects you emphasize in your analysis

93
commands/linear/start-project.md Normal file
View File

@@ -0,0 +1,93 @@
# Start Linear Project
Plan and create a new Linear project for a feature or initiative.
## Prerequisites
**Recommended:** Activate a role first (e.g., `/roles/techlead`) to load relevant codebase rules.
If you haven't loaded rules yet, read the appropriate ones:
- Backend work: `.claude/rules/backend/*.md` and `.claude/rules/dataclasses/laravel-data.md`
- Frontend work: `.claude/rules/frontend/*.md`
- Full-stack work: Both backend and frontend rules
## Workflow
### 1. Understand the Feature
Ensure you thoroughly understand what needs to be built:
- If they provided a description, confirm your understanding
- If not, ask them to describe the feature/task
- Ask clarifying questions about scope, requirements, and acceptance criteria
- Identify any technical constraints, dependencies, or integration points
### 2. Identify Git Branch
Determine which branch this feature will be developed on:
- Use Bash: `git branch --show-current`
- Ask the user: "I see you're on branch `[branch-name]`. Is this the correct branch for this feature, or would you like to specify a different one?"
- Store the branch name to include in the project description
### 3. Create Linear Project
Create a new Linear project:
- Use `mcp__linear-server__create_project` with comprehensive details
- Use a clear, descriptive name for the project
- Include a detailed description in Markdown format:
```markdown
## Branch
`[branch-name]`
## Purpose
[What problem this solves or what value it provides]
## Scope
[What's included and what's explicitly out of scope]
## Technical Approach
[High-level architecture or approach - reference patterns from rules]
## Dependencies
[Any related systems, APIs, or services]
```
- Set the appropriate team (ask user if unclear)
- Set target date if the user provides one
### 4. Break Down into Issues
Use the **linear-issue-writer** skill to create detailed issues:
- Activate the skill: `Skill tool with command: "linear-issue-writer"`
- Break the feature down into logical, implementable tasks
- **Write issues assuming someone else will implement them** - include full context
- Each issue should contain:
- Clear title describing what needs to be done
- Detailed description with background context
- Specific acceptance criteria
- Technical guidance (files to modify, patterns to follow, services to use)
- Links to relevant documentation or related code
- Any gotchas or important considerations
- Order issues logically (dependencies first)
- Assign appropriate labels and priorities
- **Reference codebase conventions** from the rules (e.g., "Create a Data class per form-data-classes.md")
### 5. Ask About Next Steps
After planning is complete, ask the user:
> "I've created the Linear project '[Project Name]' with [X] issues for implementation. What would you like to do next?"
> - Start implementing now (use `/linear/work-on-issue` to begin)
> - Stop here and continue later (you can resume with `/linear/work-on-issue [issue-id]`)
> - Review the plan first (I can walk through the issues)
Provide them with the Linear project ID/URL for reference.
## Notes
- Plan thoroughly - assume handoff to another person/session
- Write issues with full context, not just task names
- Keep the user informed at each step
- Ask for approval before creating multiple Linear issues
- Reference specific codebase patterns in issues
- Good planning makes implementation smoother for anyone

223
commands/linear/work-on-issue.md Normal file
View File

@@ -0,0 +1,223 @@
# Work on Linear Issue
Load and implement a specific Linear issue.
## Usage
`/linear/work-on-issue <issue-id>`
Example: `/linear/work-on-issue PRO-123`
## Prerequisites
**Recommended:** Activate an appropriate role first:
- `/roles/backend-engineer` - For backend issues
- `/roles/frontend-engineer` - For frontend issues
- `/roles/fullstack-engineer` - For full-stack issues
- `/roles/techlead` - For planning/architecture issues
If no role is active, you'll work as a general engineer.
## Workflow
### 1. Load Issue Context
**Fetch the Issue:**
- Use `mcp__linear-server__get_issue` with the issue ID
- Read the complete issue description and acceptance criteria
- Note the current status and any existing comments
**Load Project Context (if available):**
- If the issue belongs to a project, use `mcp__linear-server__get_project`
- Read the project description to understand:
- **Branch** - Which branch this work belongs to
- **Purpose** - Why this feature exists
- **Technical Approach** - Overall architecture
- **Dependencies** - Related systems
**Analyze Issue Type:**
- Determine if this is primarily a backend, frontend, or fullstack task by reading:
- Issue title and description
- Technical guidance in the description
- File paths or components mentioned
- Labels/tags on the issue
**Verify Role Match:**
- Check if your current role matches the issue type:
- **Backend Engineer** → Backend task ✓
- **Frontend Engineer** → Frontend task ✓
- **Fullstack Engineer** → Any task ✓
- **Tech Lead** → Any task ✓ (focus on architecture)
- **No role** → Any task ✓ (general approach)
- If there's a mismatch, warn the user:
> "⚠️ **Role Mismatch Detected**
>
> I'm currently acting as a **[current-role]**, but this issue appears to be primarily **[issue-type]** work based on:
> - [Reason 1, e.g., "Issue mentions Vue components"]
> - [Reason 2, e.g., "File paths reference frontend directory"]
>
> **Recommendation:** Activate `/roles/[suggested-role]` first for better context and conventions.
>
> Would you like me to:
> - **Proceed anyway** with my current [role] perspective?
> - **Wait** while you activate the correct role?"
- Wait for user confirmation before proceeding with a mismatched role
**Verify Branch:**
- Get current branch: `git branch --show-current`
- If project specifies a branch and you're on a different one:
- Warn: "⚠️ This issue is for branch `[project-branch]`, but you're on `[current-branch]`. Would you like me to switch branches or continue on the current branch?"
- Wait for user decision
### 2. Update Issue to "In Progress"
- Use `mcp__linear-server__update_issue` to set status to "In Progress"
- This signals to the team that work has started
### 3. Implement the Issue
Work on the issue based on your active role:
**Backend Engineer:**
- Follow backend conventions from loaded rules
- Create: Models, Data classes, Services, Controllers, Form Requests, Tests
- Ensure proper validation, testing, and pattern adherence
- Focus on code quality and maintainability
**Frontend Engineer:**
- Follow frontend conventions from loaded rules
- Create: Vue components, composables, TypeScript types
- Check for existing reusable components first
- Ensure proper UX and accessibility
- Focus on component quality and user experience
**Fullstack Engineer:**
- Implement both backend and frontend
- Ensure clean integration between layers
- Design APIs that serve frontend needs
- Test end-to-end functionality
**Tech Lead:**
- Focus on architectural correctness
- Set patterns for others to follow
- Document technical decisions
- Think about long-term maintainability
### 4. Test Your Implementation
**Backend:**
- Write comprehensive tests
- Run tests: `./vendor/bin/sail php artisan test --filter=YourTest`
- Ensure all tests pass
**Frontend:**
- Test manually in the browser
- Check responsive design
- Verify user interactions work correctly
### 5. Update Issue to "Done"
When implementation is complete:
**Update Status:**
- Use `mcp__linear-server__update_issue` to set status to "Done"
**Add Implementation Comment:**
- Use `mcp__linear-server__create_comment` with detailed summary
**Comment Format:**
```markdown
✅ Implementation complete
**Summary:**
[1-3 sentences describing what was implemented and how it works]
**Changes:**
- `app/Services/ReportService.php:45` - Brief description of change
- `app/Data/CreateReportData.php:1` - Brief description of change
- `tests/Feature/ReportExportTest.php:1` - Brief description of change
**Uncertainties/Concerns:**
[Only if applicable - implementation decisions you're unsure about or potential issues]
⚠️ Token refresh interval is set to 15 minutes. May need adjustment for production.
**Testing:**
✅ All tests passing (8 new tests added)
[or]
✅ Tested manually in browser - all interactions working correctly
```
## Notes
- Always update Linear at start (In Progress) and finish (Done)
- Include file references with line numbers: `path/to/file.php:123`
- Be specific about uncertainties so reviewers know what to check
- Keep comments concise but informative
- If you discover additional work needed, ask if you should create a new Linear issue
- Follow conventions from your active role's loaded rules
## Example Sessions
### Example 1: Role Matches Task
```
User: /roles/backend-engineer
[Backend engineer role activated, rules loaded]
User: /linear/work-on-issue PRO-456
You: Loading issue PRO-456: "Add export functionality to reports"
This is a backend task (mentions Services, Controllers, API endpoints).
You're currently acting as Backend Engineer ✓
Branch: feature/report-export (you're on it ✓)
I'll update the issue to "In Progress" and begin implementation.
[Updates Linear, implements, tests]
You: Issue PRO-456 complete! Created ReportExportService, added API endpoint, wrote tests.
Marking as Done in Linear.
```
### Example 2: Role Mismatch (Warning Given)
```
User: /roles/backend-engineer
[Backend engineer role activated]
User: /linear/work-on-issue PRO-789
You: Loading issue PRO-789: "Create export dialog component"
⚠️ **Role Mismatch Detected**
I'm currently acting as a **Backend Engineer**, but this issue appears to be primarily **Frontend** work based on:
- Issue title mentions "dialog component"
- Description references Vue components in resources/js/
- Labels include "frontend"
**Recommendation:** Activate `/roles/frontend-engineer` first for better context and conventions.
Would you like me to:
- **Proceed anyway** with my current Backend Engineer perspective?
- **Wait** while you activate the correct role?
User: Wait
You: Understood. Please activate `/roles/frontend-engineer` and then run `/linear/work-on-issue PRO-789` again.
```
### Example 3: Fullstack or Tech Lead (No Warning)
```
User: /roles/fullstack-engineer
User: /linear/work-on-issue PRO-101
You: Loading issue PRO-101: "Create export dialog component"
This is a frontend task. As a Fullstack Engineer, I can handle this ✓
[Proceeds with implementation]
```