" --body "$(cat <<'EOF' <body> EOF )" ``` **Option C: Draft PR** - add `--draft` flag to create as draft: ```bash gh pr create --base main --draft --title "<title>" --body "..." ``` **Useful flags:** - `--fill` - Auto-fill title and body from commit info - `--fill-first` - Use only the first commit for title/body - `--fill-verbose` - Include full commit messages in body - `--draft` - Create as draft PR - `--dry-run` - Preview without creating ## PR Format ### Title Format Use conventional commit style: ```text <type>(<scope>): <description> ``` **Types:** `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` **Examples:** - `feat(editor): add vim macro support` - `fix(documents): resolve save race condition` - `refactor(color-theme): simplify OKLCH conversion` ### Body Format ```markdown ## Summary Brief 1-2 sentence description of what this PR does and why. ## Changes - Bullet point list of specific changes - Group related changes together - Include file/module names when helpful ## Test Plan - [ ] Manual testing steps or automated tests that verify the change - [ ] Edge cases considered ``` ### Step 3: Show Result After creating the PR, display the URL with: ```bash gh pr view --json url --jq '.url' ``` --- --- title: Push: Commit and Push to Remote description: Combines commit creation with conventional message and push to remote in one command tool: claude category: instruction tags: ['git', 'commits', 'workflow', 'conventional-commits'] url: https://alexop.dev/prompts/claude/claude-push-command --- # Push: Commit and Push to Remote description: Commit staged changes and push to remote allowed-tools: Bash(git status), Bash(git diff:*), Bash(git log:*), Bash(git add:*), Bash(git commit:*), Bash(git push:*), Bash(git rev-parse:*), Bash(git remote:*) model: haiku # Commit and Push I have gathered information about your changes. Here are the results: <git_status> !`git status` </git_status> <staged_diff> !`git diff --cached` </staged_diff> <unstaged_diff> !`git diff` </unstaged_diff> <recent_commits> !`git log --oneline -10` </recent_commits> <current_branch> !`git rev-parse --abbrev-ref HEAD` </current_branch> <remote_info> !`git remote -v` </remote_info> ## Instructions ### Step 1: Commit (if there are changes) 1. **Analyze the diffs** above to understand what changed. 2. **Stage files** if needed (skip already staged files, skip files that shouldn't be committed like `.env`). 3. **Generate a conventional commit message** following this format: ```text <type>(<scope>): <description> [optional body] ``` Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore` 4. **Create the commit** using a HEREDOC for proper formatting: ```bash git commit -m "$(cat <<'EOF' type(scope): description EOF )" ``` ### Step 2: Push 5. **Push to remote** using the current branch: ```bash git push origin <current-branch> ``` If the branch doesn't have an upstream, use: ```bash git push -u origin <current-branch> ``` 6. **Show the result** with `git log -1` to confirm the commit, and verify the push succeeded. --- --- title: Refactor Page Object: Test Pattern Refactoring description: Refactors Vue component tests to use the Page Object Pattern for better maintainability and readability tool: claude category: instruction tags: ['testing', 'vue', 'refactoring', 'page-object-pattern', 'vitest'] url: https://alexop.dev/prompts/claude/claude-refactor-page-object-command --- # Refactor Page Object: Test Pattern Refactoring description: Refactor a Vue component test to use the Page Object Pattern argument-hint: [test-file-path] # Page Object Pattern Refactoring Refactor the test file located at @$1 to use the **Page Object Pattern**. ## Context Analyze the component import in @$1 to understand the component being tested. You need to abstract all UI interactions into a helper function. ## Refactoring Rules 1. **Create the Page Object Factory**: * Define an async function `create<ComponentName>Page()` at the **bottom** of the test file. * Move the `renderApp` or component rendering logic inside this function. * Return an object containing getters and action methods. 2. **Encapsulate Elements**: * Create getters (e.g., `getSubmitButton`, `getSearchInput`). * Use semantic queries: `getByRole`, `getByLabelText`, `getByPlaceholderText`. * **Strict rule**: Do not expose `screen` or `userEvent` directly in the test body; they must be accessed via the page object. 3. **Define Actions**: * Create semantic action methods (e.g., `searchFor(term)`, `submitForm()`). * Return promises for all actions. 4. **Test Body Cleanup**: * Instantiate the page object at the start of each test: `const page = await createXyzPage();`. * Replace all `await user.type(...)` and `screen.getBy...` calls with methods from `page`. ## Target Code Style Use this example as the ground truth for the desired output structure: ```typescript // BEFORE: // const searchInput = screen.getByPlaceholderText('Search...'); // await user.type(searchInput, 'test'); // AFTER: // const page = await createMyComponentPage(); // await page.searchFor('test'); // Page Object Structure (at bottom of file): async function createMyComponentPage() { await renderApp(MyComponent, {}, '/my-route'); return { // Getters getSearchInput: () => screen.getByPlaceholderText('Search...'), getSubmitButton: () => screen.getByRole('button', { name: 'Submit' }), // Actions searchFor: async (term: string) => { await user.type(screen.getByPlaceholderText('Search...'), term); await user.click(screen.getByRole('button', { name: 'Submit' })); } }; } --- --- title: Review CodeRabbit: Process AI Code Reviews description: Agent that processes CodeRabbit review comments with technical rigor - verifies suggestions before implementing and pushes back when wrong tool: claude category: agent tags: ['code-review', 'coderabbit', 'github', 'pull-requests', 'workflow'] url: https://alexop.dev/prompts/claude/claude-review-coderabbit-command --- # Review CodeRabbit: Process AI Code Reviews description: Fetch CodeRabbit review comments and process them with technical rigor - verify before implementing, push back when wrong allowed-tools: Bash(gh *), Bash(git *), Bash(pnpm typecheck*), Bash(pnpm lint*), Bash(pnpm test*), Bash(pnpm build*), Read, Glob, Grep, Edit, Write # Review CodeRabbit Feedback ## PR Context <current_branch> !`git branch --show-current` </current_branch> <pr_info> !`gh pr view --json number,title,state,url 2>&1` </pr_info> <coderabbit_reviews> !`gh pr view --json reviews --jq '.reviews[] | select(.author.login == "coderabbitai") | {state: .state, body: .body}' 2>&1` </coderabbit_reviews> <coderabbit_comments> !`gh pr view --json comments --jq '.comments[] | select(.author.login == "coderabbitai") | .body' 2>&1` </coderabbit_comments> <review_threads> !`gh api graphql -f query='query($owner: String!, $repo: String!, $pr: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $pr) { reviewThreads(first: 100) { nodes { id isResolved path line comments(first: 10) { nodes { body author { login } } } } } } } }' -F owner="$(gh repo view --json owner -q .owner.login)" -F repo="$(gh repo view --json name -q .name)" -F pr="$(gh pr view --json number -q .number)" 2>&1 || echo "Could not fetch review threads"` </review_threads> --- ## Decision Tree | Condition | Action | |-----------|--------| | No PR found | Branch has no PR. Create one first with `gh pr create` | | No CodeRabbit comments | No feedback to process. Done. | | Comments found | Continue to Review Reception Protocol below | --- ## Review Reception Protocol **CORE PRINCIPLE:** Verify before implementing. Ask before assuming. Technical correctness over social comfort. ### The Response Pattern ``` FOR EACH CodeRabbit suggestion: 1. READ: Complete feedback without reacting 2. UNDERSTAND: Restate requirement in own words 3. VERIFY: Check against codebase reality 4. EVALUATE: Technically sound for THIS codebase? 5. RESPOND: Technical acknowledgment or reasoned pushback 6. IMPLEMENT: One item at a time, test each ``` ### Forbidden Responses **NEVER say:** - "You're absolutely right!" (explicit CLAUDE.md violation) - "Great point!" / "Excellent feedback!" (performative) - "Let me implement that now" (before verification) - "Thanks for catching that!" (performative gratitude) **INSTEAD:** - Restate the technical requirement - Ask clarifying questions if needed - Push back with technical reasoning if wrong - Just fix it (actions > words) --- ## Verification Checklist BEFORE implementing any CodeRabbit suggestion: - [ ] **Technically correct** for THIS codebase? - [ ] **Breaks existing functionality?** Check tests, grep for usage - [ ] **Reason for current implementation?** May be intentional - [ ] **Works on all platforms/versions?** Check compatibility - [ ] **Does reviewer understand full context?** AI may lack context ### YAGNI Check ``` IF suggestion adds "proper" or "professional" features: grep codebase for actual usage IF unused: Consider removing (YAGNI) instead of improving IF used: Then implement properly ``` --- ## When To Push Back Push back when: - Suggestion breaks existing functionality - Reviewer lacks full context (common with AI reviewers) - Violates YAGNI (unused feature) - Technically incorrect for this stack - Legacy/compatibility reasons exist - Conflicts with architectural decisions **How to push back:** ``` "Checked [X] - current implementation does [Y] because [reason]. Changing to [suggestion] would [break/conflict with] [Z]. Keep current approach? Or is there context I'm missing?" ``` --- ## Processing CodeRabbit Feedback ### Step 1: Categorize Each Item | Category | Priority | Action | |----------|----------|--------| | Security/Breaking | HIGH | Verify immediately, fix if confirmed | | Type errors/Bugs | HIGH | Verify locally, fix if real | | Style/Formatting | LOW | Check if matches project conventions | | "Best practices" | VERIFY | Check if actually applies here | | Refactoring suggestions | VERIFY | Check if code is actually used | ### Step 2: Verify Before Acting For each suggestion: 1. **Read the referenced file** - understand current implementation 2. **Check tests** - does current code pass? Would change break them? 3. **Grep for usage** - is this code actually called? 4. **Consider context** - why might it be written this way? ### Step 3: Implementation Order ``` IF multiple items: 1. Clarify anything unclear FIRST 2. Then implement in order: - Security/Breaking issues - Confirmed bugs - Simple fixes (imports, typos) - Complex changes (refactoring) 3. Test each fix individually 4. Verify no regressions 5. RESOLVE each comment after addressing (see Resolution Protocol) ``` --- ## Acknowledging Correct Feedback When feedback IS correct: ``` - "Fixed. [Brief description of what changed]" - "Good catch - [specific issue]. Fixed in [location]." - [Just fix it and show in the code] ``` When you pushed back and were wrong: ``` "Verified this and you're correct. [Brief reason]. Fixing." ``` No long apologies. State correction factually and move on. --- ## Resolution Protocol **Every CodeRabbit comment MUST be resolved after processing.** > **Note:** Resolving review threads requires the GraphQL API. The REST API does not support thread resolution. ### Step 1: List Unresolved Review Threads ```bash # Get all review threads with resolution status (GraphQL required) gh api graphql -f query=' query($owner: String!, $repo: String!, $pr: Int!) { repository(owner: $owner, name: $repo) { pullRequest(number: $pr) { reviewThreads(first: 100) { nodes { id isResolved path line comments(first: 10) { nodes { body author { login } } } } } } } }' -F owner="{owner}" -F repo="{repo}" -F pr="$(gh pr view --json number -q .number)" ``` ### Step 2a: Resolve After Implementation When you implement a suggestion, resolve the thread directly (reply is optional - the commit speaks for itself): ```bash # Resolve a review thread by its GraphQL node ID gh api graphql -f query=' mutation($threadId: ID!) { resolveReviewThread(input: {threadId: $threadId}) { thread { isResolved } } }' -f threadId="THREAD_NODE_ID" ``` ### Step 2b: Reply and Resolve Without Implementation When you decide NOT to implement, reply with reasoning then resolve: ```bash # Reply to a review thread (requires thread's GraphQL node ID) gh api graphql -f query=' mutation($threadId: ID!, $body: String!) { addPullRequestReviewThreadReply(input: { pullRequestReviewThreadId: $threadId, body: $body }) { comment { body } } }' -f threadId="THREAD_NODE_ID" -f body="Not implementing: [reason] - Current implementation does X because Y - Suggested change would [break/conflict with] Z" # Then resolve the thread gh api graphql -f query=' mutation($threadId: ID!) { resolveReviewThread(input: {threadId: $threadId}) { thread { isResolved } } }' -f threadId="THREAD_NODE_ID" ``` ### Helper: Get Owner and Repo ```bash # Extract owner/repo from current git remote gh repo view --json owner,name -q '"\(.owner.login)/\(.name)"' ``` ### Resolution Checklist For EACH CodeRabbit comment: - [ ] Evaluated (implemented or rejected with reason) - [ ] Response added (if rejecting - explain why) - [ ] Thread resolved via GraphQL mutation **Goal: Zero unresolved CodeRabbit comments when done.** --- ## Common CodeRabbit Patterns | Pattern | Verify | |---------|--------| | "Consider using X instead of Y" | Check if X works in this context | | "This could be simplified" | Check if simplification handles edge cases | | "Missing error handling" | Check if errors are handled elsewhere | | "Unused import/variable" | Verify with grep, may be used dynamically | | "Type could be more specific" | Check if generic type is intentional | | "Add documentation" | Check project conventions on docs | --- ## Red Flags - STOP and Verify If you catch yourself: - Agreeing without checking the code - Implementing before understanding why current code exists - Not testing changes - Batch implementing without individual verification **STOP. You are being performative. Return to verification.** --- ## Summary **External AI feedback = suggestions to evaluate, not orders to follow.** 1. Read all feedback first 2. Verify each item against codebase 3. Push back on incorrect suggestions 4. Implement confirmed issues one at a time 5. Test each change 6. **Resolve every comment** (implemented or rejected with reason) No performative agreement. Technical rigor always. Zero unresolved comments. --- --- title: Vitest: Run Tests and Fix Failures description: Runs Vitest test suite and systematically fixes any failing tests tool: claude category: instruction tags: ['testing', 'vitest', 'debugging', 'workflow'] url: https://alexop.dev/prompts/claude/claude-vitest-command --- # Vitest: Run Tests and Fix Failures description: Run Vitest tests and fix any failing tests allowed-tools: Bash(pnpm run test:vitest), Bash(pnpm test:vitest), Bash(vitest) # Vitest Test Runner I have run the Vitest test suite. Here are the results: <test_results> !`pnpm run test:vitest --run 2>&1 || true` </test_results> ## Instructions 1. **Analyze the `<test_results>`** above. - If all tests pass, no action is needed. - If tests are failing, identify the root cause from the error messages. 2. **Fix failing tests** by either: - Fixing bugs in the source code that caused the test to fail - Updating tests if they are outdated or incorrect 3. **Verify** by running the test command again to confirm all tests pass. --- --- title: Learn: Analyze Conversation for Documentation description: Analyzes conversation for insights worth preserving and saves them to the project's documentation tool: claude category: skill tags: ['documentation', 'learning', 'knowledge-capture', 'workflow'] url: https://alexop.dev/prompts/claude/claude-learn-command --- # Learn: Analyze Conversation for Documentation description: Analyze conversation for learnings and save to docs folder argument-hint: [optional topic hint] model: claude-opus-4-5-20251101 allowed-tools: Read, Write, Edit, Glob, Grep, AskUserQuestion # Learn from Conversation Analyze this conversation for insights worth preserving in the project's documentation. **If a topic hint was provided via `$ARGUMENTS`, focus on capturing that specific learning.** **If no hint provided, analyze the full conversation for valuable insights.** ## Phase 1: Deep Analysis Think deeply about what was learned in this conversation: - What new patterns or approaches were discovered? - What gotchas or pitfalls were encountered? - What architecture decisions were made and why? - What conventions were established? - What troubleshooting solutions were found? Only capture insights that are: 1. **Reusable** - Will help in future similar situations 2. **Non-obvious** - Not already common knowledge 3. **Project-specific** - Relevant to this codebase If nothing valuable was learned, say so and exit gracefully. ## Phase 2: Categorize & Locate Read existing docs to find the best home. Look for a `docs/` folder or similar documentation directory in the project. If no existing doc fits, propose a new doc file with kebab-case naming. **Note:** CLAUDE.md stays stable as the entry point. All detailed learnings go to `/docs` only. ## Phase 3: Draft the Learning Format the insight to match existing doc style: - Clear heading describing the topic - Concise explanation of the insight - Code examples if applicable - Context on when this applies ## Phase 4: User Approval (BLOCKING) Present your proposed changes: 1. What insight you identified 2. Where you'll save it (existing doc + section, or new file) 3. The exact content to add **Wait for explicit user approval before saving.** ## Phase 5: Save After approval, save the learning and confirm what was captured. --- --- title: Genereate new Prompt for Copilot description: Custom instructions for TypeScript development with strict typing tool: copilot category: prompt tags: ['typescript', 'code-quality'] url: https://alexop.dev/prompts/copilot/copilot-make-prompt --- # Genereate new Prompt for Copilot agent: agent model: Claude Sonnet 4.5 (copilot) tools: ['edit', 'search/codebase', 'think'] description: From a short task description, generate a Copilot `.prompt.md` file at `.github/prompts/` ## Copilot Prompt File Generator (VS Code prompt files) Turn a short description into a complete VS Code Copilot **prompt file** (`.prompt.md`) saved under `.github/prompts`, following the official prompt-file structure and best practices. > If any required value is missing, infer sensible defaults **without** back-and-forth. ## Behavior priority (in order) 1. Successfully create a valid `.prompt.md` file that VS Code can run. 2. Do **not** ask follow-up questions; infer sensible defaults from inputs. 3. If a step is impossible, stop and briefly explain the problem in chat. --- ## Inputs Normalize all inputs by trimming whitespace. - **Task description** (required) → `${input:desc:Briefly describe what the prompt should do}` - If empty or only whitespace, stop and report the error in chat. - **Prompt file base name (kebab-case, filename-safe)** → `${input:name:${fileBasenameNoExtension}-prompt}` - **Prompt display name** (optional; shown after `/` in chat) → `${input:promptName}` - **Argument hint** (optional; hint text in chat input) → `${input:argumentHint}` - **Agent / mode** (`ask` | `edit` | `agent`; default `agent`) → `${input:agent:agent}` - If `${input:agent}` is not one of `ask`, `edit`, `agent`, treat it as `agent`. - **Model** (optional; defaults to model picker) → `${input:model}` - **Tools** (optional; comma-separated tool or tool-set names) → `${input:tools}` - Parse into an array: split by `,`, trim, drop empty entries, deduplicate. - Support patterns like `serverName/*` for MCP servers when provided. - **Additional references** (optional; comma-separated relative paths) → `${input:refs}` - Parse into an array: split by `,`, trim, drop empty entries, deduplicate. > Treat “workspace prompt files” as files under `.github/prompts`. This generator only creates **workspace** prompt files. --- ## What to generate Create **one** `.prompt.md` file with the official VS Code prompt-file structure: ### 1) YAML frontmatter (only non-empty keys) Use the following keys, matching the VS Code docs: - `description`: ≤ 90 chars summary crafted from `${input:desc}`. - If `${input:desc}` is longer, truncate at a word boundary. - `name`: from `${input:promptName}` if provided, otherwise: - Use the computed base filename (without extension) as a reasonable default. - `argument-hint`: from `${input:argumentHint}` if provided. - `agent`: from normalized `${input:agent}` (`ask`, `edit`, or `agent`). - `model`: from `${input:model}` if provided. - `tools`: from parsed `${input:tools}` if non-empty (YAML list). Omit any key whose value is empty, `null`, or an empty array. Example shape (for preview only): ```yaml description: Review Python code for security issues and suggest fixes name: review-python-security argument-hint: Paste the Python code you want reviewed agent: ask model: gpt-4.1 tools: - search - githubRepo ``` ### 2) Body (clear, actionable, self-contained) The body is the prompt text VS Code sends to the LLM when the prompt is run. It must be structured and aligned with best practices. Use the following sections in this **exact order**: 1. `## Task` - 1–3 sentences summarizing what the prompt does and when to use it, based on `${input:desc}`. 2. `## Instructions` - Numbered, deterministic steps to accomplish `${input:desc}`. - Use imperative mood and active voice. - Clearly describe: - What the AI should do. - How it should use any selections, files, or inputs. - Any language / framework / version constraints that are explicitly implied by the task (do not invent constraints). _When relevant, encourage using VS Code prompt variables to make the prompt reusable and flexible, for example:_ - `${selection}` or `${selectedText}` for code under review or to transform. - `${file}`, `${fileBasename}`, `${fileDirname}`, `${fileBasenameNoExtension}` when operating on the current file. - `${workspaceFolder}`, `${workspaceFolderBasename}` for workspace-level operations. - `${input:variableName}` / `${input:variableName:placeholder}` to pass user parameters into the prompt (for things like component names, API names, etc.). 3. `## Expected output` - A bulleted or numbered list describing the exact output format the AI should produce, for example: - Required sections and headings. - When to use fenced code blocks (and which languages). - When to use tables, lists, or checklists. - Any JSON or structured formats, including required fields. 4. `## References` (include only if `${input:refs}` is non-empty) - Bullet list of reference files, each as a **relative Markdown link**, for example: - `[API specification](docs/api.md)` - Use the parsed `${input:refs}` values directly as relative paths from `.github/prompts`. - Do not reference files that are not listed in `${input:refs}`. - When relevant, suggest how the AI should use these references (for example, “Follow the guidelines in [custom instructions](../docs/custom-instructions.md) instead of duplicating them here”). _If the prompt benefits from agent tools (like `githubRepo`, `search`, or others), you may mention them in the body using the VS Code tool reference syntax, for example: `#tool:githubRepo`._ 5. `## Done when` - A checklist that clearly states the completion criteria for this prompt. - Use `- [ ]` items. - Include checks like: - Output matches the described structure. - Any required examples of input and output are included. - Any referenced files are linked correctly and actually used. - The prompt does not depend on hidden context beyond the described variables and references. In the body: - Encourage `${selection}`, `${file}`, and input variables **only when they add clarity and reuse**, not by default. - Avoid depending on external context beyond: - Workspace-relative files you’ve linked. - Built-in variables (`${selection}`, `${file}`, `${workspaceFolder}`, input variables). - Use **Markdown** consistently (headings, lists, code blocks). - Do **not** leak internal environment details or paths outside `.github/prompts`. --- ## File operations Use the available workspace/file tools (for example, `edit`) to actually modify the repository; do not simulate edits in prose. 1. **Compute base slug:** - If `${input:name}` is provided and non-empty, start from that. - Otherwise, **slugify** `${input:desc}` as follows: - Lowercase the string. - Replace any sequence of characters outside `[a-z0-9]` with a single `-`. - Collapse repeated `-` into one. - Trim leading and trailing `-`. - Optionally truncate the slug to a safe length (for example, 60 characters) without cutting inside a word if practical. 2. **Apply extension:** - Use `<slug>.prompt.md` as the base filename. 3. **Ensure folder exists:** - Ensure `.github/prompts` exists, creating it if necessary. - Treat this folder as the workspace prompt-file folder. 4. **Resolve collisions:** - If `.github/prompts/<slug>.prompt.md` already exists, try: - `.github/prompts/<slug>-1.prompt.md`, - `.github/prompts/<slug>-2.prompt.md`, etc. - Increment the numeric suffix until a unique path is found. 5. **Write file:** - Write the YAML frontmatter and body to `.github/prompts/<final-name>.prompt.md`. - Never overwrite existing files; always create a new file. --- ## Return in chat (always) After successfully writing the file: - Provide a one-line confirmation with the final saved **path**, wrapped in backticks, for example: _`Created \`.github/prompts/my-task.prompt.md`._` - Show a short frontmatter preview (3–6 lines) in a fenced `yaml` code block, using the final values, for example: ```yaml description: Review Python code for security issues and suggest fixes name: review-python-security agent: ask model: gpt-4.1 tools: - search - githubRepo ``` - If `${input:refs}` parsed to a non-empty list, output: - “Reference files:” followed by a bullet list of the detected reference paths. - If `${input:refs}` is empty or only whitespace, output: - “No reference files provided.” If any required step fails (for example, unable to write the file), explain briefly what failed and which step you reached. --- ## Tool selection (least-privilege) Start with **no additional tools** beyond those configured for this agent. Add tools only if strictly necessary and available in the current environment. - Prefer read-only tools when you need to inspect the workspace (for example, `search`, `search/codebase`, `problems`, `usages`, `extensions`, `vscodeAPI`), if they exist. - Use write/exec tools only when needed: - Create scaffolding/files → `edit` or `new`. - Run commands → `runCommands`. - Build/run/test → `runTasks`, `runTests`. - Local preview → `openSimpleBrowser`. - Public code examples → `githubRepo`. - Fetch a specific URL’s content → `fetch`. If a tool mentioned above is not available in this environment, omit it and choose the minimal available alternative. Do **not** substitute more powerful or riskier tools than necessary. --- ## Implementation algorithm (you execute now) 1. Parse `${input:desc}`, `${input:name}`, `${input:promptName}`, `${input:argumentHint}`, `${input:agent}`, `${input:model}`, `${input:tools}`, and `${input:refs}` and normalize them as described above. 2. Validate that `${input:desc}` is non-empty; if it is empty, report the error in chat and stop. 3. Craft the `description` field (≤ 90 chars) from `${input:desc}`. 4. Build the YAML frontmatter with `description`, `name`, `argument-hint`, `agent`, `model`, and `tools`, omitting empty keys. 5. Write the body with: - `## Task` summary, - `## Instructions` numbered steps (using variables and tools when helpful), - `## Expected output` section, - optional `## References` section (if refs exist), - `## Done when` checklist. 6. Ensure `.github/prompts` exists, compute a safe, unique filename, and write the file. 7. Reply in chat with the confirmation line, frontmatter preview, and reference files list (or “No reference files provided”). --- ## Style & best practices (aligning with VS Code docs) - Clearly describe what the prompt should accomplish and what output format is expected. - Provide or request examples of expected input and output when that helps guide responses. - Prefer referencing common guidelines or custom instructions via Markdown links instead of duplicating them. - Leverage built-in variables like `${selection}`, `${file}`, `${workspaceFolder}`, and `${input:*}` to keep prompts flexible and reusable. - Use the editor’s run/play button (and `/promptName` in chat) to test prompts, then refine wording and output format instructions to improve determinism. - Be concise, precise, and neutral; no emojis or fluff. - Use **active voice** and imperative mood. - Avoid ambiguous language like “a few” or “some”. - Do **not** leak internal environment details or paths outside `.github/prompts`. --- ## Example transformation (illustrative; do **not** save) **Input desc:** “Create a prompt to review Python code for security issues and suggest fixes.” - `description:` “Review Python code for security issues and suggest fixes” - `name:` `review-python-security` - `argument-hint:` “Paste the Python code you want reviewed” - `agent:` `ask` - `tools:` might include `search`, `githubRepo` **Body should:** - Use `${selection}` to receive the code under review. - In `## Instructions`, instruct the AI to identify common security issues (injection, insecure deserialization, SSRF, secrets, weak crypto) and suggest fixes. - In `## Expected output`, require a Markdown list grouped by severity with code examples of safer alternatives. - In `## Done when`, ensure the output follows the described format and covers all detected issues. --- ## “Done when” checklist - A unique file exists at `.github/prompts/<name>.prompt.md`. - Frontmatter uses only official VS Code fields (`description`, `name`, `argument-hint`, `agent`, `model`, `tools`) with non-empty valid values. - Body contains `## Task`, `## Instructions`, `## Expected output`, optional `## References` (if refs exist), and `## Done when`. - Any `${input:refs}` were linked via relative Markdown paths in the `## References` section. - The prompt body uses VS Code variables and tool references (`${selection}`, `${input:*}`, `#tool:<name>`) when beneficial. - Chat reply includes the final path, frontmatter preview, and reference files list (or “No reference files provided”). ---

{{ title }}

{{ title }}

Alex Opalic

Your Cart

{{ product.name }}

{{ region }}

Most Related Posts

Route Leave Guard Demo

Transformers.js

ML-powered multilingual translation in Vue!

Counter: {{ count }}

Pokemon Data:

Species Data:

Evolution Data:

{{ title }}

{{ title }}

{{ title }}

Alex Opalic

Your Cart

{{ product.name }}

{{ region }}

Most Related Posts

Route Leave Guard Demo

Transformers.js

ML-powered multilingual translation in Vue!

Counter: {{ count }}

Pokemon Data:

Species Data:

Evolution Data:

{{ title }}