Przejdź do treści
← Kurs M09L03 · Instrukcje i Prompt Files ⚡
⚡ Zaawansowany M09L03 M09 · Lekcja 3 z 4 10 min Ćwiczenie

Prompt Files (.prompt.md): reużywalne przepływy pracy

Jak tworzyć pliki .prompt.md jako reużywalne szablony dla powtarzalnych zadań - generowanie testów, code review, onboarding.

Czego się nauczysz

  • Czym prompt file różni się od custom instructions i custom agenta
  • Jak zbudować prosty, reużywalny workflow w .prompt.md
  • Jak sterować agentem, modelami i narzędziami z poziomu frontmatter

Nie każdy workflow zasługuje na własnego agenta

To bardzo ważne rozróżnienie.

Jeśli masz powtarzalne zadanie, nie musisz od razu budować custom agenta, skilla albo całego ekosystemu narzędzi. Często wystarczy prompt file.

Prompt files to lekkie, ręcznie uruchamiane przepływy pracy zapisane jako .prompt.md.

Najważniejsza różnica względem instrukcji jest prosta:

  • instrukcje wchodzą automatycznie do kontekstu
  • prompt file uruchamiasz świadomie, gdy chcesz wykonać konkretny workflow

Kiedy prompt file ma sens

Dokumentacja podaje bardzo trafne use case’y:

  • generowanie komponentu według wzorca
  • code review
  • uruchamianie i naprawianie testów
  • przygotowanie pull requesta
  • onboarding do powtarzalnego typu zadania

To rzeczy, które robisz regularnie, ale nie potrzebujesz dla nich osobnej persony działającej cały czas.

Gdzie prompt files żyją

Workspace-level prompt files domyślnie trafiają do .github/prompts, a user-level mogą być przechowywane na poziomie profilu VS Code.

To znaczy, że możesz mieć dwa rodzaje workflow:

  • współdzielone zespołowo, commitowane do repo
  • osobiste, prywatne i synchronizowane między urządzeniami

To rozdzielenie będzie bardzo ważne w następnej lekcji.

Co można ustawić w frontmatter

To najmocniejsza część prompt files.

W frontmatter możesz określić między innymi:

  • name
  • description
  • argument-hint
  • agent
  • model
  • tools

W praktyce oznacza to, że nie zapisujesz tylko treści promptu. Zapisujesz też warunki jego wykonania.

Przykład:

---
name: review-api
description: Review zmian w API pod kątem breaking changes
agent: ask
tools: ['search/codebase', 'read/problems']
argument-hint: Podaj moduł albo ścieżkę API do analizy
---
Przeanalizuj wskazane API pod kątem breaking changes, niespójności kontraktów i brakujących testów regresyjnych.


Zwróć wynik jako listę ryzyk i rekomendacji.

To już nie jest luźny prompt. To gotowa komenda operacyjna dla zespołu.

Jak uruchamiać prompt file

Docs pokazują trzy sensowne ścieżki:

  • wpisujesz / i nazwę promptu w Chat view
  • używasz Chat: Run Prompt z Command Palette
  • odpalasz prompt z play buttona w otwartym pliku

To bardzo wygodne, bo prompt staje się czymś pomiędzy dokumentacją a narzędziem.

Prompt file vs instructions vs custom agent

Najprostszy filtr decyzyjny wygląda tak:

  • instructions: gdy reguła ma działać automatycznie
  • prompt file: gdy chcesz ręcznie odpalać powtarzalny workflow
  • custom agent: gdy potrzebujesz stałej persony z własnymi narzędziami, modelem i handoffami

Jeśli to rozróżnienie jest niejasne, ludzie zwykle nadużywają custom agentów do rzeczy, które spokojnie dałoby się zamknąć w jednym prompt file.

Tool priority w promptach jest bardzo praktyczne

Jedna z ważniejszych sekcji dokumentacji dotyczy priorytetu narzędzi. Kolejność jest taka:

  1. narzędzia wskazane w prompt file
  2. narzędzia z custom agenta, jeśli prompt się do niego odwołuje
  3. domyślne narzędzia wybranego agenta

To oznacza, że prompt file może bardzo precyzyjnie zawęzić albo doprecyzować środowisko pracy, nawet jeśli zespół korzysta z różnych agentów bazowych.

Dobra praktyka: nie duplikuj instrukcji w promptach

Dokumentacja podpowiada sensowną zasadę: zamiast kopiować te same reguły do każdego prompt file, odwołuj się do instructions.

To ma dwie zalety:

  • prompt pozostaje krótki i czytelny
  • zmiana reguł projektu nie wymaga edycji pięciu osobnych workflow

Prompt file powinien mówić przede wszystkim:

  • co zrobić
  • w jakim formacie oddać wynik
  • jakich narzędzi użyć
  • jakie dane wejściowe są potrzebne

Generowanie promptów przez AI też ma sens

Aktualne docs wspierają /create-prompt, które pomaga wygenerować .prompt.md z odpowiednim frontmatter i treścią.

To dobre przy starcie, ale po wygenerowaniu prompt trzeba przetestować. Dokumentacja wręcz sugeruje iterację przez play button i dopracowywanie frontmatter oraz treści na podstawie realnego zachowania.

To dobry nawyk: prompt file traktuj jak kod. Wersjonuj, odpalaj, poprawiaj.

Ćwiczenie praktyczne

Stwórz własny prompt file do jednego z tych zadań:

  • review zmian w API
  • generowanie testów regresyjnych
  • przygotowanie checklisty przed PR-em

Potem zrób trzy iteracje:

  1. Ustal agent.
  2. Zawęź tools do minimum potrzebnego dla zadania.
  3. Doprecyzuj format odpowiedzi i dane wejściowe.

Na końcu porównaj jakość odpowiedzi przed i po zawężeniu narzędzi. To zwykle bardzo dobrze pokazuje, że dobry prompt file jest bardziej środowiskiem wykonania niż samym tekstem polecenia.

Kluczowe wnioski

  • Prompt file to ręcznie uruchamiany, reużywalny workflow zapisany w .prompt.md.
  • Nie zastępuje instrukcji ani custom agentów, tylko wypełnia środek między nimi.
  • Frontmatter pozwala sterować agentem, modelem, argumentami i narzędziami.
  • Prompt file powinien być krótki, konkretny i testowany iteracyjnie.
  • Najlepsze prompty współpracują z instructions, zamiast kopiować ich treść.

Co dalej

Masz już dwa poziomy personalizacji: reguły automatyczne i workflow uruchamiane ręcznie. Został ostatni praktyczny problem: co trzymać u siebie, a co commitować do repozytorium.