Files

Ludovico Magnocavallo 81f72e8068 Add FAST Prerequisites Skill and Gemini Skill Test Harness (#3979 )

* initial version of a FAST pre-install skill

* first round of testing

* Update fast-0-org-setup-prereqs skill with improved UX and local path handling

- Add explicit lockout warning and stop condition if the user is not a member of the provided Admin Principal group.
- Streamline bootstrap project selection to only prompt for an override if the active gcloud project is rejected.
- Restrict dataset discovery strictly to the `fast/stages/0-org-setup/datasets/` directory.
- Improve location handling by referencing `defaults.schema.json` for Standard GCP and auto-configuring fixed regions for GCD.
- Add comprehensive `local_path` management: prompt for customization, create directories, move `defaults.yaml` to the local data folder, and symlink `0-org-setup.auto.tfvars` back to the stage directory.

* add testing scenarios, implement initial changes for scenario 2

* move skills

* move to a skills/fast subfolder

* Refactor fast-0-org-setup prereqs skill

* Add skill-turn-harness utility tool

* Use relative markdown links for skill references

* Use descriptive titles for markdown links in skill references

* Add descriptions to each phase in the prerequisites workflow map

* Use backslash for markdown line breaks in skill map

* Update README security warning to mention default .gitignore

* shebang

* Update fast prereqs skill rules to force sequential question flow and refine harness tool with proper ctrl+c handling and slugified log paths

* Move playbook-gcp-dev.yaml to fast/prerequisites/gcp-dev.yaml and update fast prerequisites

* docs(skill-turn-harness): detail autonomous pond testing approach

* docs(skill-turn-harness): add final_state_checks to pond architecture and update toc

* Refine fast prereqs SKILL and gcp-dev playbook to strictly align with one-question-at-a-time rule

* feat(skill-turn-harness): update playbook schema for autonomous persona mode

* feat(skill-turn-harness): implement autonomous persona testing mode and fallback logic

* docs(skill-turn-harness): document the three modes of testing and update ToC

* implement timeout, schema validation, configurable cli

* chore: remove accidentally committed log files

* chore: ignore logs directory

* feat(skill-harness): implement tool execution interception, configurable workspace, and modularized validation

* feat(skill-harness): add model configuration and update README

* fix(skill-harness): automatically inject -y flag to gemini commands

* docs(skill-harness): add TODO.md with analysis for skill environment dependencies

* feat(skill-harness): add working_dir support and clean up fixtures

- Implement working_dir in harness to run tests in specific directories.
- Rename test fixtures and playbooks to be more descriptive.
- Add E2E test for working_dir.
- Apply code quality improvements to harness.py (imports, linting).
- Update README with working directory considerations and usage notes.
- Update phase3-bootstrap-and-iam.md skill doc to add execution rule against creating temp scripts.

* fix: capture customer_id and respect relative paths

* Implement isolated temp workspace sandboxing with symlinks in test harness

* Configure GCD manual autonomous playbook and align Phase 3/4 steps order

* Fix linting and schema tests failures

- Add missing license headers to tools/skill-turn-harness files.

- Fix trailing spaces and newlines in playbooks.

- Ignore tools directory in schema tests workflow.

TAG=agy

CONV=1bb75453-c3e2-448b-bae9-8e332a068012

* Fix Python formatting with yapf

TAG=agy

CONV=1bb75453-c3e2-448b-bae9-8e332a068012

* Refactor skill-turn-harness to use Antigravity SDK

- Migrated harness from gemini-cli subprocesses to Antigravity SDK.
- Implemented real-time step streaming and console logging.
- Added color-coded terminal output (dark gray headers, blue inputs, pink outputs).
- Collapsed excessive newlines in streamed thoughts.
- Excluded harness codebase from workspace copy to prevent agent cheating.
- Enabled skills folder copy to resolve agent lookup loops.
- Added key validation and CLI --debug flag.

* Fix autonomous turn layout: print Turn ID before execution

- Moved the [Autonomous Turn X] header print to before running the agent turn.
- This groups the real-time thinking and tool calls under the correct Turn ID block, instead of displaying them before the label.

* Remove obsolete .log.md from prerequisites skill directory

2026-05-22 17:16:54 +00:00

4.5 KiB

Raw Blame History

name, description

name	description
fast-0-org-setup-prereqs	Guides the user step-by-step through the prerequisites for the FAST 0-org-setup stage, supporting both Standard GCP and Google Cloud Dedicated (GCD) environments. Use when a user asks to prepare or run prerequisites for 0-org-setup or bootstrap the FAST landing zone.

FAST 0-org-setup Prerequisites Guide

Core Principles & Execution Rules

[!CRITICAL] Understanding Turn Boundaries: You are running in a turn-based execution environment.

You receive one user message, then you can think and run tools.

Once you decide you need input from the user (e.g. to choose an environment or confirm a principal), you MUST output your question in a text response and STOP execution immediately (do not call more tools).

You CANNOT receive the user's answer in the same turn.

You MUST NOT simulate, guess, or assume the user's response in your subsequent thinking blocks during the same turn. You must wait for the next turn to receive the actual input.

Do NOT Skip Steps or Make Assumptions: You MUST NOT skip any phases or steps, even if you think they are redundant or if you find information on the system (like active credentials) that suggests a step is already complete. You MUST execute every step sequentially, in order, and wait for explicit user input/confirmation at each step boundary.

Strictly One Question at a Time: You MUST NOT bundle multiple questions or steps together in a single response. Ask exactly one question, wait for the user's answer, and only then proceed to the next question or action.

Step-by-Step Execution: Never implement a single "magical" flow. Go through each step one at a time, explaining context and asking for confirmation.

Execution Choice: Respect the user's execution preference (automatic via run_shell_command vs. manual copy/paste) throughout the entire workflow unless the user explicitly instructs you to change it. This preference will be gathered during Phase 1.
File Modifications: Always use replace or write_file. Never use opaque shell commands (like sed, echo >>, or cat <<EOF >>). Show proposed edits and ask for confirmation before applying them so the user can see what we're doing.
YAML Validation: Validate generated YAML using yamllint -c .yamllint --no-warnings <file>. If the command is not available, ask the user if they prefer to a) install it, b) have you install it (pip install yamllint), or c) skip validation.
Resuming Mid-Flow: If the user is resuming a previously interrupted session, ask them which Phase or Step they left off at, or assess the current state by reading previously generated files (e.g., defaults.yaml, 0-org-setup.auto.tfvars). Read the corresponding reference file for the identified phase and resume execution directly from that point.

Workflow Map

Guide the user through the following sequence strictly in order. Before starting a phase, read its corresponding reference document to get the exact instructions, commands, and logic.

Phase 1: Environment & Authentication

Description: Determine the target environment (Standard GCP or GCD) and ensure the user is properly authenticated.
Reference: Environment & Authentication

Step 1: Environment Assessment & Initialization (Standard vs GCD)
Step 2: Authentication

Phase 2: Admin Principal & Baseline Info

Description: Define the core administrative identity and gather essential baseline data like Organization and Billing IDs.
Reference: Admin Principal & Baseline Info

Step 3: Admin Principal Definition (Group vs Single User)
Step 4: Baseline Information Gathering (Org ID, Billing ID, Billing Access Scenarios)

Phase 3: Bootstrap Project & IAM

Description: Assign the necessary organization-level IAM roles and set up a temporary project for API quota tracking.
Reference: Bootstrap Project & IAM

Step 5: IAM Role Assignments
Step 6: Bootstrap Project Setup (Creation and API enablement)

Phase 4: Configuration & Wrap-up

Description: Generate the FAST dataset configuration, handle existing organization policies, and prepare for the final Terraform apply.
Reference: Configuration & Wrap-up

Step 7: Configuration Generation (Datasets, defaults.yaml, local paths)
Step 8: Organization Policy Import Check
Step 9: Wrap-up & Apply

4.5 KiB Raw Blame History