user-story-implementer
Instructions
You are acting as an autonomous sub-agent to implement a user story or task managed via GitHub Issues.
Your objective is to complete exactly one user story or task from the GitHub repository, verify its acceptance criteria, push the changes in a new branch, and create a Pull Request.
PREREQUISITE: The GitHub CLI (gh) MUST be installed and fully authenticated (gh auth login) for this skill to function.
Workflow
- Identify the Next Task: Before picking up new work, check for unfinished business first.
- Check for rejected PRs first: Run
gh pr list --state open --author "@me" --search "review:changes_requested". If any PRs have changes requested, address the feedback on the oldest one before picking up a new issue. Check out the branch, read the review comments withgh pr view <pr-number> --comments, fix the issues, push, and re-request review. - Check for dependency blockers: When selecting an issue, read its comments for "Depends on: #<issue>" patterns. Run
gh issue view <dependency-number> --json state -q '.state'to check if the dependency is resolved. If it's still open, skip this issue and grab the next one. - If a specific issue number is provided, use
gh issue view <issue-number>. - If a specific feature prefix or label is provided (e.g.,
AUTH), rungh issue list --label "user-story" --label "<prefix>" --limit 5 --search "sort:created-asc"(fetch 5 to allow skipping blocked issues). - If a milestone is provided, use
gh issue list --label "user-story" --milestone "<milestone-name>" --limit 5 --search "sort:created-asc". - If no specific scope is provided, you MUST ask the user to clarify which feature prefix, milestone, or issue number they want to work on to avoid picking up tasks from unrelated design docs.
- Once the next available (unblocked) issue is identified, note the issue number, title, and body (which contains the Acceptance Criteria).
- Check for rejected PRs first: Run
- State Management: Before starting work, assign the issue to yourself (or the current user) using
gh issue edit <issue-number> --add-assignee "@me". This provides visibility and prevents conflicts.
More from eho/agent-skills
user-story-reviewer
Review an implemented user story or task (via GitHub Pull Request) for completeness, test coverage, and code quality. Use this when asked to QA, review a PR, verify implementation, or as a follow-up to the user-story-implementer skill.
32prd
Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD. Triggers on: create a prd, write prd for, plan this feature, requirements for, spec out.
26prd-to-github-milestone
Parses a Product Requirements Document (PRD) to extract User Stories and creates corresponding GitHub Issues. It can optionally link them to a GitHub Milestone. This skill acts as a setup phase for GitHub-native issue tracking. Make sure to use this skill whenever the user asks to "send the PRD to GitHub", "create issues from the PRD", "setup the milestone", or mentions turning requirements into actionable GitHub issues.
18public-repo-explorer
Instructs the agent on how to efficiently browse public GitHub repositories using a local shallow clone. You MUST use this skill whenever the user asks you to scan, examine, clone, or extract information from a public Git repository, or whenever they provide a GitHub URL to explore.
14design-doc-reviewer
Review a design document for completeness, clarity, and quality — including user story readiness for agent implementation. Produces structured feedback with specific gaps, strengths, and a prioritized improvement checklist. Use when asked to review a design doc, critique a design, check a spec, review the PRD, or audit the requirements.
13post-implementation-reviewer
Performs a comprehensive post-implementation review of an entire design document. Verifies all user stories are complete, implementation aligns with the original design, code quality is high, and all documentation (READMEs, usage guides, API docs) is consistent and updated. Use this when asked to "do a final review of the design doc", "verify completion", "check if the feature is ready for release", or "audit the implementation".
9