القائمة
Create a Product Requirements Document through an interactive interview, then file it as a GitHub issue. Use to write a PRD or spec or when the user runs /write-prd.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Expert guidance for ffuf web fuzzing during penetration testing, including authenticated fuzzing with raw requests, auto-calibration, and result analysis
Catch up on uncommitted work — read all uncommitted git changes (staged, unstaged, untracked) into the conversation to establish context. Use when resuming work or when the user runs /catchup.
Bring a JavaScript repo up to the standard Code Quality Playbook baseline (Prettier, ESLint ratchet, husky + lint-staged, CI lint gate, optional JSDoc typecheck) idempotently — present pieces are skipped, missing ones are added — then optionally migrate the repo from npm to pnpm (lockfile import, packageManager pin, build-script allow-list, Firebase functions-framework fix, npm cleanup). Manual, global. Use only when the user runs /code-quality.
Create git commits for staged and unstaged changes using the emoji commit-message format, with optional push. Use when the user wants to commit or check in changes, or runs /commit.
Execute one complete unit of work end-to-end through tight feedback loops — understand it, plan it, build it, validate it, commit it — never advancing a phase until its feedback signal is green. Manual and global: runs only when the user invokes /do-work or another skill explicitly hands it a scoped unit of work. Use to "do the work", "execute this task/plan/issue", "build and validate and commit", or as the execution engine other planning skills delegate to.
Set up Playwright E2E testing framework for any project — auto-detects stack, auth, routes, and selectors
| name | write-prd |
| description | Create a Product Requirements Document through an interactive interview, then file it as a GitHub issue. Use to write a PRD or spec or when the user runs /write-prd. |
Create a Product Requirements Document through an interactive interview process, then submit it as a GitHub issue in the current repository.
Before doing anything else, run:
gh repo view --json nameWithOwner -q .nameWithOwner
cd into the correct project directory and run /write-prd again. Stop here.gh not authenticated), inform the user and stop. Do not proceed without a confirmed repo.Store the owner/repo value — use it for all gh commands in this session.
Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
Wait for their response before proceeding.
Explore the repo to verify the user's assertions and understand the current state of the codebase. Look at project structure, relevant modules, existing patterns, and anything that relates to the problem described.
Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
Keep asking questions until there are no ambiguities left. Do not rush this step.
Wait for the user's answers before proceeding.
Sketch out the major modules you will need to build or modify to complete the implementation. Actively look for opportunities to extract deep modules that can be tested in isolation.
A deep module (as opposed to a shallow module) is one which encapsulates a lot of functionality in a simple, testable interface which rarely changes.
Present the modules to the user and ask:
Wait for approval before proceeding.
Once you have a complete understanding of the problem and solution, write the PRD using the template below and submit it as a GitHub issue using:
gh issue create --repo <owner/repo> --assignee @me --title "PRD: <feature name>" --body "$(cat <<'EOF'
<prd content here>
EOF
)"
Use the confirmed owner/repo from Step 0.
After creation, display the issue URL to the user.
## Problem Statement
The problem that the user is facing, from the user's perspective.
## Solution
The solution to the problem, from the user's perspective.
## User Stories
A LONG, numbered list of user stories. Each user story should be in the format of:
1. As an <actor>, I want a <feature>, so that <benefit>
This list should be extremely extensive and cover all aspects of the feature.
## Implementation Decisions
A list of implementation decisions that were made. This can include:
- The modules that will be built/modified
- The interfaces of those modules that will be modified
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions
Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
## Testing Decisions
A list of testing decisions that were made. Include:
- A description of what makes a good test (only test external behavior, not implementation details)
- Which modules will be tested
- Prior art for the tests (i.e. similar types of tests in the codebase)
## Out of Scope
A description of the things that are out of scope for this PRD.
## Further Notes
Any further notes about the feature.
--repo flag on all gh commands with the confirmed owner/repo