A skill that guides agents through structured agile development workflows for Gitea repositories by intelligently invoking commands in sequence. Uses checkpoint-based flow control to auto-progress between steps while pausing at key decision points.
Fetches gitea-workflow from jwynia/agent-skills and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/gitea-workflow
Restart Cursor to activate gitea-workflow. Access via /gitea-workflow in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
A skill that guides agents through structured agile development workflows for Gitea repositories by intelligently invoking commands in sequence. Uses checkpoint-based flow control to auto-progress between steps while pausing at key decision points.
When to Use This Skill
Use this skill when:
Working with a Gitea-hosted repository
Starting work for the day ("run morning standup", "start my day")
Working on a task ("implement next task", "continue working")
Completing a development cycle ("finish this task", "prepare PR")
# Auto-detect state and continue from where you are/gitea-workflow
# Start specific workflow phase/gitea-workflow --phase task-cycle
/gitea-workflow --phase daily-morning
/gitea-workflow --phase daily-evening
/gitea-workflow --phase sprint-start
/gitea-workflow --phase sprint-end
# Resume work on specific task/gitea-workflow --task TASK-123
# Preview what would happen without executing/gitea-workflow --dry-run
Task Cycle Phase
The primary workflow for completing a single task from selection to merge.
Step 1: Sync Reality
Ensure context network matches actual project state.
Run: sync --last 1d --dry-run
Purpose: Detect drift between documented and actual state
Output: Sync report showing completions, partial work, divergences
Step 2: Select Task
Identify the next task to work on.
Run: next
Purpose: Find highest priority ready task
Output: Task ID, title, branch name suggestion
CHECKPOINT: TASK_SELECTED
Pause to confirm task selection
User can accept or choose different task
On accept: continue to implementation
Step 3: Implement
Test-driven development in isolated worktree.
Run: implement [TASK-ID]
Purpose: Create worktree, write tests first, implement, verify
Output: Working implementation with passing tests
CHECKPOINT: IMPL_COMPLETE
Pause after implementation completes
Show test results and coverage
On success: continue to review
Step 4: Review
Quality validation of implementation.
Run: review-code --uncommitted
Run: review-tests --uncommitted
Purpose: Identify quality issues, security concerns, test gaps
Output: Review reports with issues and recommendations
CHECKPOINT: REVIEWS_DONE
Display combined review results
If critical issues: must address before continuing
If no issues: auto-continue to PR prep
User decides: apply recommendations now or defer
Step 5: Apply Recommendations (Conditional)
Address review findings intelligently.
Run: apply-recommendations [review-output]
Purpose: Apply quick fixes now, defer complex changes to tasks
Output: Applied fixes + created follow-up tasks
Step 6: Prepare PR
Create pull request with full documentation.
Run: pr-prep
Purpose: Validate, document, and create PR
Output: PR created with description, tests verified
CHECKPOINT: PR_CREATED
Display PR URL and CI status
Wait for CI checks to complete (verify manually or via API script)
Persist progress to source-of-truth documentation.
Run: Part of pr-complete (Phase 6)
Purpose: Update epic file (task → complete), unblock dependents, update project status
Output: Backlog and project status reflect actual progress
Why this step matters: Without it, completed tasks remain marked "ready" in backlog files and project status stays stale. Internal tracking files are session-scoped; the backlog and status files are the persistent source of truth.
Run sequence:
1. sync --last 1d --dry-run # What actually happened yesterday
2. status --brief --sprint # Current sprint health
3. groom --ready-only # What's ready to work on
Output: Clear picture of today's priorities
Evening Wrap-up (~10 min)
Run sequence:
1. checklist # Ensure nothing lost
2. discovery # Capture learnings
3. sync --last 1d # Update task statuses
Output: Knowledge preserved, state synchronized
Run sequence:
1. sync --all # Full reality alignment
2. groom --all # Comprehensive grooming
3. plan sprint-goals # Architecture and goals
4. status --detailed # Baseline metrics
Output: Sprint plan with groomed, ready backlog
Sprint End (~90 min)
Run sequence:
1. sync --sprint # Final sprint sync
2. retrospective # Capture learnings
3. audit --scope sprint # Quality review
4. status --metrics # Sprint metrics
5. maintenance --deep # Context network cleanup
Output: Sprint closed, learnings captured, ready for next
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
