Tworzenie autonomicznych potoków deweloperskich za pomocą plików agents.md i skills.md w Antigravity

1. Wprowadzenie

W tym ćwiczeniu pokażemy, jak skonfigurować zabawny, wspomagany przez AI autonomiczny zespół programistów AI bezpośrednio na komputerze za pomocą Antigravity IDE. Utworzysz działającą aplikację, przeprowadzając wymaganie przez cały cykl życia – od specyfikacji technicznej po ostateczne wdrożenie – za pomocą zaawansowanego przepływu pracy skills.md i agents.md.

Zamiast ograniczać się do określonego stosu technologicznego lub pisać złożone skrypty administracji w Pythonie, użyjemy prostego podejścia bez kodu, w którym Twoje wymagania będą przechodzić przez zautomatyzowany cykl oparty na 3 podstawowych zasadach Antigravity:

  1. agents.md: aby dokładnie określić, kto wchodzi w skład Twojego zespołu AI (kierownik produktu, programista frontendu, specjalista ds. kontroli jakości, specjalista ds. DevOps).
  2. Umiejętności i skills.md: dedykowany katalog, w którym definiujesz solidne umiejętności techniczne i reguły przekazywania artefaktów jako modułowe .md pliki.
  3. Workflows (workflows/): aby zdefiniować niestandardowe polecenia po ukośniku, które płynnie łączą członków zespołu AI w autonomiczny potok.

Łącząc te 3 elementy natywnie w Antigravity, poprowadzisz Gemini, aby w pełni zautomatyzować tworzenie aplikacji gotowej do wdrożenia w środowisku produkcyjnym od początku do końca.

Czego się nauczysz

  • Inicjowanie obszaru roboczego: skonfiguruj projekt tak, aby był dobrze rozumiany przez Antigravity.
  • Definiowanie zespołu: utwórz plik agents.md, aby określić wyspecjalizowane persony AI.
  • Programowanie umiejętności: utwórz szczegółowe pliki .md w katalogu skills/, aby zdefiniować ścisłe reguły techniczne i iteracyjne pętle przeróbek.
  • Definiowanie niestandardowych przepływów pracy: utwórz polecenie po ukośniku /startcycle, aby zautomatyzować przepływ pracy w Studio.
  • Uruchamianie reakcji łańcuchowej: użyj jednego polecenia, aby automatycznie i wydajnie wykonać cały potok z udziałem wielu agentów.

Co wypróbujesz

  • Jak oddzielić inżynierię promptów AI od kodu aplikacji.
  • Jak utworzyć agenta, który aktywnie wstrzymuje działanie, aby interpretować komentarze i edycje użytkownika w wygenerowanych plikach Markdown.
  • Jak tworzyć dynamiczne umiejętności generowania i wdrażania kodu niezależne od języka.
  • Jak tworzyć niestandardowe polecenia makr (przepływy pracy) w IDE z agentami.

Czego potrzebujesz

Zanim zaczniesz

  1. Upewnij się, że masz zainstalowane Antigravity IDE (dostępne na stronie antigravity.google).
  2. Otwórz Antigravity IDE i upewnij się, że masz zainicjowany nowy, dedykowany obszar roboczy.
  3. Podczas pracy w trybie edytora miej otwarty terminal.

2. Inicjowanie obszaru roboczego

Ponieważ Antigravity natywnie rozpoznaje pliki przepływu pracy umieszczone w katalogu .agents, skonfigurowanie autonomicznego potoku programistycznego jest tak proste jak utworzenie kilku standardowych folderów.

Możesz skonfigurować obszar roboczy:

  1. Otwórz Antigravity IDE.
  2. Otwórz Menedżera agentów . W dowolnym momencie możesz przełączać się między Menedżerem agentów a edytorem, naciskając CMD+E (Mac) lub CTRL+E (Windows) albo klikając przyciski Otwórz edytor i Otwórz Menedżera agentów w prawym górnym rogu paska menu. .
  3. Kliknij + Otwórz obszar roboczy.

Aby rozpocząć nową rozmowę w obszarze roboczym, wybierz odpowiedni obszar roboczy na karcie Rozpocznij rozmowę lub kliknij przycisk plusa obok nazwy obszaru roboczego na pasku bocznym.

45e7241be5552e42.png

  1. Kliknij Otwórz nowy obszar roboczy, nazwij obszar roboczy skills-codelab i wybierz katalog lokalny. Dzięki temu agent będzie miał określony folder główny, w którym będzie mógł tworzyć pliki bez zaśmiecania innych projektów. Gdy to zrobisz, przejdź do widoku edytora, a następnie wykonaj kroki (5), (6) i (7).

d84ba507939a5efc.png

  1. Kliknij prawym przyciskiem myszy i utwórz folder skills-codelab.
  2. W nim utwórz 2 katalogi: production_artifacts i app_build.
  3. Utwórz katalog .agents, a w nim foldery workflows i skills.

(Alternatywnie) Jeśli wolisz używać terminala, możesz natychmiast wygenerować tę strukturę, uruchamiając:

mkdir skills-codelab && cd skills-codelab
mkdir -p .agents/workflows .agents/skills
mkdir production_artifacts app_build

Upewnij się, że folder wygląda tak:

7234ea48c2b175a7.png

Do czego służą te nowe foldery?

  • .agents/: to specjalny katalog natywnie rozpoznawany przez Antigravity. Umieszczając w nim pliki, rozszerzasz wbudowane działanie AI w Antigravity.
  • skills/: ten folder służy do przechowywania szczegółowych instrukcji technicznych (.md plików) dla AI. Informuje AI, jak wykonywać określone zadania, takie jak pisanie kodu czy wdrażanie aplikacji, zastępując jeden duży, mylący prompt modułowymi krokami.
  • production_artifacts/: to nasz folder współdzielony, w którym zautomatyzowani członkowie zespołu będą celowo umieszczać pliki, aby następny agent mógł je odczytać.
  • app_build/: wyznaczony obszar roboczy na potrzeby kodu aplikacji. Agent Full-Stack Engineer wygeneruje cały kod (np. package.json, app.py, komponenty React) i zapisze go bezpośrednio w tym folderze, izolując źródło aplikacji od instrukcji AI.

3. Definiowanie zespołu (agents.md)

Najpierw musimy poinformować Antigravity, kto pracuje nad tym projektem. Zamiast przechowywać instrukcje w 4 różnych zagnieżdżonych folderach projektu, centralizujemy tożsamość naszego zespołu. Utwórz plik w lokalizacji .agents/agents.md:

Dlaczego potrzebujemy różnych person?

Gdy poprosisz AI o utworzenie całej aplikacji od zera, może się ona łatwo przytłoczyć, jeśli zmusisz ją do pełnienia jednocześnie roli architekta, programisty, testera i lidera wdrożenia. Centralizując te role w agents.md, zapobiegasz dezorientacji AI. Kierownik produktu skupia się tylko na wymaganiach, programista tylko na generowaniu kodu, a specjalista ds. kontroli jakości tylko na naprawianiu błędów. Na każdym etapie potoku masz do dyspozycji wyspecjalizowanych ekspertów.

Plik agents.md rozwiązuje ten problem, centralizując różne persony zespołu:

  1. Kierownik produktu (@pm): skupia się tylko na ogólnym obrazie. Pisze plik Technical_Specification.md i zarządza procesem zatwierdzania z Tobą (człowiekiem).
  2. Programista Full-Stack (@engineer): nie przejmuje się planowaniem. Po prostu bierze specyfikację kierownika produktu i skupia się wyłącznie na pisaniu wysokiej jakości kodu w dowolnym języku, który zatwierdzisz.
  3. Specjalista ds. kontroli jakości (@qa): pełni rolę świeżego spojrzenia. Zamiast pisać nowe funkcje, skupia się wyłącznie na znajdowaniu brakujących zależności, błędów składniowych lub błędów logicznych w kodzie programisty.
  4. Specjalista ds. DevOps (@devops): skupia się wyłącznie na środowisku wykonawczym. Wie, jak odczytywać terminal, instalować pakiety (npm install, pip install) i uruchamiać serwer lokalny.
# 🤖 The Autonomous Development Team

## The Product Manager (@pm)
You are a visionary Product Manager and Lead Architect with 15+ years of experience.
**Goal**: Translate vague user ideas into comprehensive, robust, and technology-agnostic Technical Specifications.
**Traits**: Highly analytical, user-centric, and structured. You never write code; you only design systems.
**Constraint**: You MUST always pause for explicit user approval before considering your job done. You are highly receptive to user feedback and will enthusiastically re-write specifications based on inline comments.

## The Full-Stack Engineer (@engineer)
You are a 10x senior polyglot developer capable of adapting to any modern tech stack.
**Goal**: Translate the PM's Technical Specification into a beautiful, perfectly structured, production-ready application.
**Traits**: You write clean, DRY, well-documented code. You care deeply about modern UI/UX and scalable backend logic.
**Constraint**: You strictly follow the approved architecture. You do not make assumptions—if the spec says Python, you use Python. You always save your code into the `app_build/` directory.

## The QA Engineer (@qa)
You are a meticulous Quality Assurance engineer and security auditor.
**Goal**: Scrutinize the Engineer's code to guarantee production-readiness.
**Traits**: Detail-oriented, paranoid about security, and relentless in finding edge cases.
**Focus Areas**: You aggressively hunt for missing dependencies in configurations, unhandled promises, syntax errors, and logic bugs. You proactively fix them.

## The DevOps Master (@devops)
You are the elite deployment lead and infrastructure wizard.
**Goal**: Take the final code in `app_build/` and magically bring it to life on a local server.
**Traits**: You excel at terminal commands and environment configurations.
**Expertise**: You fluently use tools like `npm`, `pip`, or native runners. You install all necessary modules seamlessly and provide the local URL directly to the user so they can see the final product!

Zwróć uwagę, jak definiujemy cele, cechy i ograniczenia dla każdej persony.

  • Cele informują agenta, jakie są jego dokładne obowiązki w potoku.
  • Cechy nadają mu osobowość behawioralną, informując, jak ma się zachowywać (np. „programista senior 10x” lub „paranoik na punkcie bezpieczeństwa”).
  • Ograniczenia działają jak ścisłe bariery (np. „nigdy nie pisz kodu”, „ściśle przestrzegaj zatwierdzonej architektury”).

Takie strukturyzowanie promptów radykalnie zmniejsza halucynacje AI i zapewnia, że agent ściśle przestrzega wymaganego przepływu pracy.

Upewnij się, że folder wygląda tak:

4. Programowanie wyspecjalizowanych umiejętności (skills/)

Szczegółowe instrukcje to klucz do magii bez kodu. Utworzymy bardzo szczegółowe pliki tekstowe dla każdej umiejętności, dzięki czemu kierownik produktu będzie aktywnie wracać do poprzednich kroków, jeśli poprosisz o przeróbkę.

1. Umiejętność specyfikacji

Ta umiejętność jest punktem początkowym. Agent kierownika produktu używa jej do przeprowadzenia wywiadu z Tobą i dopracowania architektury, zanim zostanie napisany jakikolwiek kod, co pozwala uniknąć wielu godzin potencjalnie zmarnowanego kodowania.

Utwórz plik .agents/skills/write_specs.md:

# Skill: Write Specs

## Objective
Your goal as the Product Manager is to turn raw user ideas into rigorous technical specifications and **pause for user approval**.

## Rules of Engagement
- **Artifact Handover**: Save all your final output back to the file system.
- **Save Location**: Always output your final document to `production_artifacts/Technical_Specification.md`.
- **Approval Gate**: You MUST pause and actively ask the user if they approve the architecture before taking any further action.
- **Iterative Rework**: If the user leaves comments directly inside the `Technical_Specification.md` or provides feedback in chat, you must read the document again, apply the requested changes, and ask for approval again!

## Instructions
1. **Analyze Requirements**: Deeply analyze the user's initial idea request.
2. **Draft the Document**: Your specification MUST include:
   - **Executive Summary**: A brief, high-level overview.
   - **Requirements**: Functional and non-functional requirements.
   - **Architecture & Tech Stack**: Suggest the absolute best framework (e.g., Python/Django, Node/Express, React/Next.js) for the job and outline the layout/API structure.

   - **State Management**: Briefly outline how data should flow.
3. Save the document to disk.
4. **Halt Execution**: Explicitly ask the user: "Do you approve of this tech stack and specification? You can safely open `Technical_Specification.md` and add comments or modifications if you want me to rework anything!" Wait for their "Yes" or feedback before the sequence continues!

Zwróć uwagę na ścisłą „bramkę zatwierdzenia”. Zamiast tworzyć całą aplikację od razu i mieć nadzieję, że wszystko będzie w porządku, AI ma wyraźne polecenie, aby wstrzymać działanie, poczekać na Twoją ostateczną decyzję i aktywnie ponownie przeczytać dokument, jeśli zostawisz komentarze w tekście.

2. Umiejętność generowania Full-Stack

Ta umiejętność jest podstawowym narzędziem do tworzenia. Agent programisty odczytuje dokładny stos technologii ze specyfikacji kierownika produktu i dynamicznie tworzy wszystkie niezbędne pliki kodu frontendu i backendu.

Utwórz plik .agents/skills/generate_code.md:

# Skill: Generate Code

## Objective
Your goal as the Full-Stack Engineer is to write the physical code based entirely on the PM's approved specification.

## Rules of Engagement
- **Dynamic Coding**: You are not limited to HTML/JS. You must write code in the exact language/framework defined in the approved `Technical_Specification.md`.
- **Save Location**: Save all your raw code, accurately retaining necessary folder structures, directly inside `app_build/`.

## Instructions
1. **Read the Spec**: Open and carefully study `production_artifacts/Technical_Specification.md`.
2. **Scaffold Structure**: Generate all core backend and frontend application files.
3. **Output**: Dump your code perfectly into the `app_build/` directory. Do not skip or summarize any code blocks. Ensure all `package.json` or `requirements.txt` files are present.

Ta umiejętność nie ma predefiniowanego stosu (np. Next.js lub Django). Opiera się ona wyraźnie na dynamicznym stosie technologii wybranym przez kierownika produktu. Oznacza to, że Twoja pojedyncza umiejętność generowania kodu działa w przypadku dowolnego frameworka zatwierdzonego w specyfikacji.

3. Umiejętność audytu

Ta umiejętność zapewnia siatkę bezpieczeństwa. Agent ds. kontroli jakości pełni rolę niezależnego recenzenta, który ma za zadanie wyszukiwać brakujące zależności i błędy logiczne w nowo wygenerowanym kodzie.

Utwórz plik .agents/skills/audit_code.md:

# Skill: Audit Code

## Objective
Your goal as the QA Engineer is to ensure the generated code is perfectly functional natively.

## Rules of Engagement
- **Target Context**: Your focus area is the `app_build/` directory.

## Instructions
1. **Assess Alignment**: Compare the raw code against the approved `Technical_Specification.md`.
2. **Bug Hunting**: Find and fix dependency mismatches, unhandled errors, and logic breaks.
3. **Commit Fixes**: Overwrite any flawed files in `app_build/` with your polished revisions.

Generatywna AI naturalnie popełnia drobne błędy składniowe podczas pisania ogromnych ilości kodu. Dzięki oddzielnej umiejętności audytu, której jedynym zadaniem jest wyszukiwanie błędów, znacznie zwiększamy szanse na pomyślne uruchomienie aplikacji.

4. Umiejętność dynamicznego wdrażania

Ta umiejętność ożywia aplikację. Agent ds. DevOps określa, jaki typ aplikacji został utworzony (Node, Python itp.), i bezpiecznie uruchamia polecenia terminala potrzebne do zainstalowania modułów i uruchomienia serwera.

Utwórz plik .agents/skills/deploy_app.md:

# Skill: Deploy App

## Objective
Your goal as DevOps is to intelligently package the application and fire up a server based on the chosen stack.

## Instructions
1. **Stack Detection**: Inspect the `Technical_Specification.md` and the files in `app_build/` to figure out what stack is being used.

2. **Install Dependencies**: Use your native terminal to navigate into `app_build/` and run `npm install`, `pip install -r requirements.txt`, or whatever is appropriate!

3. **Host Locally**: Execute the appropriate native terminal command (e.g., `npm run dev`, `python3 app.py`) to start a background server.
4. **Report**: Output the clickable localhost link to the user and celebrate a successful launch!

Wykorzystujemy możliwość bezpiecznego uruchamiania natywnych poleceń terminala w IDE.

Agent działa jak prawdziwy inżynier DevOps, dynamicznie określając, jakie polecenie instalacji należy uruchomić na podstawie plików, które faktycznie widzi w folderze app_build/.

(Opcjonalnie) 5. Umiejętność wdrażania w Cloud Run

Jeśli chcesz przenieść aplikację bezpośrednio do środowiska produkcyjnego zamiast tylko uruchamiać ją lokalnie, możesz utworzyć alternatywną umiejętność wdrażania. Ponieważ Antigravity działa bezpośrednio na Twoim komputerze lokalnym, AI może bezproblemowo korzystać z lokalnie uwierzytelnionego interfejsu wiersza poleceń gcloud.

Utwórz plik .agents/skills/deploy_cloud_run.md:

# Skill: Deploy to Cloud Run

## Objective
Your goal as DevOps is to package the application into a container and deploy it to Google Cloud Run.

## Instructions
1. **Verify Environment**: Ensure the necessary files for the chosen tech stack are in `app_build/`.
2. **Containerize**: Use the IDE terminal to navigate to `app_build/` and run `gcloud run deploy --source .`. 
3. **Configure**: If prompted by the CLI tool, automatically select the default region and allow unauthenticated invocations so the web app is public.
4. **Report**: Output the live production Google Cloud Run URL to the user!

5. Definiowanie niestandardowego polecenia ukośnikowego

Do czego służy niestandardowe polecenie po ukośniku?

Zapisując ten plik tekstowy w lokalizacji .agents/workflows/ , rejestrujesz zupełnie nowe polecenie bezpośrednio w interfejsie czatu Antigravity.

Zamiast ręcznie podawać AI instrukcje krok po kroku („Działaj jako kierownik produktu i napisz specyfikację…” a potem „OK, teraz działaj jako programista i napisz kod…”), polecenie /startcycle działa jako zautomatyzowany orkiestrator. Płynnie łączy zdefiniowane persony i ich konkretne umiejętności w ciągłą, zautomatyzowaną sekwencję. Utworzymy pojedyncze makro, które będzie obsługiwać przekazywanie między agentami, wyraźnie zarządzając pętlą przeróbek na etapie kierownika produktu.

Utwórz plik .agents/workflows/startcycle.md:

---
description: Start the Autonomous AI Developer Pipeline sequence with a new idea
---

When the user types `/startcycle <idea>`, orchestrate the development process strictly using `.agents/agents.md` and `.agents/skills/`.

### Execution Sequence:
1. Act as the **Product Manager** and execute the `write_specs.md` skill using the `<idea>`.
   *(Wait for the user to explicitly approve the spec. If the user provides feedback or adds comments directly to the Markdown file, act as the PM again to re-read and revise the document. Loop this step until they type "Approved").*
2. Shift context, act as the **Full-Stack Engineer**, and execute the `generate_code.md` skill.
3. Shift context, act as the **QA Engineer**, and execute the `audit_code.md` skill.
4. Shift context, act as the **DevOps Master**, and execute the `deploy_app.md` skill.

Upewnij się, że folder wygląda tak:

de21eeb6012ddbcd.png

6. Uruchamianie reakcji łańcuchowej

Gdy zespół i reguły są oficjalnie zdefiniowane w Antigravity, możesz bez wysiłku uruchomić cały przepływ pracy.

Podaj Antigravity prompt:

  1. W polu czatu Menedżera agentów wpisz / , aby otworzyć menu poleceń niestandardowych. Wybierz lub wpisz startcycle.
  2. Podaj swój pomysł:
/startcycle "I need a fast, real-time chat application for customer support on my ecommerce website."

Usiądź wygodnie i współpracuj:

  1. Gemini staje się kierownikiem produktu, tworzy solidną specyfikację i prosi Cię o zatwierdzenie.
  2. Otwórz plik Technical_Specification.md w edytorze IDE, dodaj kilka uwag (np. „Zamiast Node użyjmy Pythona”) i poproś agenta o przeróbkę. Agent samodzielnie poprawi plik.
  3. Gdy zatwierdzisz plik, Gemini natywnie przełączy kontekst na programistę, używając zatwierdzonej specyfikacji do napisania kodu backendu i frontendu.
  4. Agent staje się specjalistą ds. kontroli jakości, naprawia błędy i zapisuje ostateczny kod.
  5. Na koniec specjalista ds. DevOps dynamicznie instaluje moduły i udostępnia aplikację w Twojej przeglądarce.

Przykładowe uruchomienie pliku Technical_Specification.md i oczekiwanie na zatwierdzenia lub komentarze

11defe4c48e874cc.png

Po zatwierdzeniu promptu przez użytkownika rozpoczyna się cały przepływ pracy.

b9af07291806ae60.png

7. Podsumowanie i dalsze kroki

Gratulacje! Wiesz już, jak wstrzykiwać do potoku agentowego pętle iteracji współpracy oraz dynamiczne generowanie aplikacji full stack!

W tym ćwiczeniu omówiliśmy te kwestie:

  • Jak mapować persony AI za pomocą pliku .agents/agents.md.
  • Jak tworzyć pętle przeróbek współpracy w pliku .agents/skills/write_specs.md, aby agent odczytywał Twoje komentarze w tekście Markdown.
  • Tworzenie dynamicznych umiejętności .md, które piszą kod w dowolnej platformie (Python, React) w zależności od zatwierdzonej specyfikacji.