ci: add gemini-manual workflow and headless agent skills (#52)
### Overview This PR introduces the headless Antigravity CLI remote GitHub Actions workflow (`gemini - manual`) and associated repository skills to enable remote development orchestration from GitHub Issues and Pull Requests. ### Key Changes 1. **GitHub Actions Workflow (`.github/workflows/gemini-manual.yml`)**: - Collaborator access guard (`OWNER`, `MEMBER`, `COLLABORATOR`). - Interactive emoji reactions (`eyes` and `rocket`). - Multi-turn conversation persistence via `actions/cache@v4` on `~/.gemini/antigravity-cli/conversations` and `brain/`. - Command dispatchers for `/plan`, `/implement`, and `/fix`. - Pre-push monorepo verification gates (`typecheck`, `lint`, `test`). 2. **Repository Skills (`.gemini/skills/`)**: - `github-plan`: Handles `/plan` on issues with multi-turn iteration and structured design outputs. - `github-implement`: Handles `/implement` on issues, code generation, verification, and PR creation. - `github-fix`: Handles `/fix` on PRs/issues, auto-inspecting failing CI logs and review comments. 3. **Project Guidelines (`GEMINI.md`)**: - Updated safety rules to allow automated GitOps workflows. --- Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.
This commit is contained in:
deytenit authored and 
GitHub committed
1 parent
118a536897
commit
4e4cac06a7
14 files changed
+857
-869
No files matched your search
@@ -0,0 +1,175 @@
|
||||
---
|
||||
name: github-fix
|
||||
description: Diagnose CI failures and review feedback on GitHub Pull Requests or Issues, repair code, verify quality checks, and commit changes.
|
||||
---
|
||||
|
||||
# GitHub Fix Skill
|
||||
|
||||
Use this skill when a user submits a `/fix` command on a GitHub Pull Request or Issue.
|
||||
|
||||
## Overview
|
||||
|
||||
The `/fix` command resolves build failures, test errors, and reviewer feedback. This skill enforces unified diagnosis, clean code repair, strict verification, and transparent progress reporting.
|
||||
|
||||
```text
|
||||
/fix [optional instructions]
|
||||
│
|
||||
├── 1. Unified Diagnosis (Fetch CI logs, inspect diff, parse comments)
|
||||
├── 2. Target Code Repair (Fix build errors and review feedback in one pass)
|
||||
├── 3. Verification (Run typecheck, lint, and tests)
|
||||
├── 4. Git Operations (Commit and push to the active branch)
|
||||
└── 5. Thread Summary (Post itemized comment with mandatory disclosure)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Operational Workflow
|
||||
|
||||
### Step 1: Unified Diagnosis
|
||||
|
||||
Collect all diagnostic context before making code edits.
|
||||
|
||||
#### Case A: Pull Request Context
|
||||
1. Identify the current PR number and branch:
|
||||
```bash
|
||||
gh pr view --json number,headRefName,baseRefName
|
||||
```
|
||||
2. Fetch failed CI workflow logs:
|
||||
```bash
|
||||
gh run view --log-failed
|
||||
```
|
||||
3. Inspect current changes in the PR:
|
||||
```bash
|
||||
gh pr diff
|
||||
```
|
||||
4. Read all review comments and discussion threads:
|
||||
```bash
|
||||
gh pr view --comments
|
||||
```
|
||||
5. Check inline review comments on specific files:
|
||||
```bash
|
||||
gh api repos/{owner}/{repo}/pulls/{pull_number}/comments
|
||||
```
|
||||
|
||||
#### Case B: Issue Context
|
||||
1. Read the issue description and thread comments:
|
||||
```bash
|
||||
gh issue view <issue-number> --comments
|
||||
```
|
||||
2. Extract error stack traces, reproduction steps, and user instructions.
|
||||
|
||||
---
|
||||
|
||||
### Step 2: Target Code Repair
|
||||
|
||||
Apply all necessary corrections in a single pass.
|
||||
|
||||
1. Address all failures from CI logs (TypeScript errors, linter violations, test failures).
|
||||
2. Apply requested changes from code review comments.
|
||||
3. Incorporate any optional user instructions provided with `/fix`.
|
||||
4. Obey all repository conventions defined in `GEMINI.md`:
|
||||
- **Strict TypeScript**: Do not use `any`, `as Type` assertions, or non-null `!` assertions. Use `castRef` from `@ermnvldmr/stl` when casting DOM references.
|
||||
- **Type Imports**: Use `import type` for type declarations.
|
||||
- **Interfaces**: Define object contracts with `interface`, not `type` aliases.
|
||||
- **TSDoc**: Add descriptive JSDoc comments to all exported symbols and interfaces.
|
||||
- **Styling**: Use Tailwind CSS v4 and `cva`. Merge class names with `cn` from `@ermnvldmr/stl`.
|
||||
- **UI Primitives**: Use React Aria hooks and Radix UI primitives.
|
||||
- **Import Boundaries**: Use relative paths for files within the same workspace package.
|
||||
|
||||
---
|
||||
|
||||
### Step 3: Verification
|
||||
|
||||
Execute the complete verification sequence. All checks must pass with zero warnings or errors before proceeding.
|
||||
|
||||
```bash
|
||||
# 1. Verify TypeScript types
|
||||
pnpm typecheck
|
||||
|
||||
# 2. Verify ESLint rules
|
||||
pnpm lint
|
||||
|
||||
# 3. Run unit and component tests
|
||||
pnpm test
|
||||
```
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If any check fails, resolve the failure immediately and rerun the verification sequence.
|
||||
|
||||
---
|
||||
|
||||
### Step 4: Git Operations
|
||||
|
||||
Stage, commit, and push the resolved changes to the active branch.
|
||||
|
||||
1. Stage modified and created files:
|
||||
```bash
|
||||
git add <modified-files>
|
||||
```
|
||||
2. Commit with standard message:
|
||||
```bash
|
||||
git commit -m "fix: apply review adjustments and CI fixes"
|
||||
```
|
||||
3. Push changes to the remote branch:
|
||||
```bash
|
||||
git push origin HEAD
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Step 5: Post Summary Comment
|
||||
|
||||
Post an itemized summary comment to the GitHub PR or Issue thread.
|
||||
|
||||
1. Format the comment with the template below.
|
||||
2. Submit the comment via GitHub CLI:
|
||||
- For a Pull Request:
|
||||
```bash
|
||||
gh pr comment <pr-number> --body "<comment-body>"
|
||||
```
|
||||
- For an Issue:
|
||||
```bash
|
||||
gh issue comment <issue-number> --body "<comment-body>"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## GitHub Comment Template
|
||||
|
||||
```markdown
|
||||
### Automated Fix Summary
|
||||
|
||||
I addressed the reported issues and review feedback.
|
||||
|
||||
#### Root Causes Identified
|
||||
- **CI / Test Failure**: `<Brief description of the failure>`
|
||||
- **Review Feedback**: `<Brief description of reviewer comments>`
|
||||
|
||||
#### Changes Applied
|
||||
- `packages/<pkg>/src/...`: Fixed `<specific problem>`
|
||||
- `services/<svc>/src/...`: Updated `<specific problem>`
|
||||
|
||||
#### Verification Results
|
||||
- `pnpm typecheck` passed (0 errors).
|
||||
- `pnpm lint` passed (0 warnings).
|
||||
- `pnpm test` passed (all tests clean).
|
||||
|
||||
Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
Before completing the task, verify every item in this checklist:
|
||||
|
||||
- [ ] Failed CI logs inspected with `gh run view --log-failed`.
|
||||
- [ ] PR diff and review comments retrieved and analyzed.
|
||||
- [ ] Code repairs satisfy all requirements without introducing regressions.
|
||||
- [ ] No `any`, `as Type`, or `!` operators introduced.
|
||||
- [ ] `pnpm typecheck` completed with 0 errors.
|
||||
- [ ] `pnpm lint` completed with 0 warnings.
|
||||
- [ ] `pnpm test` completed with all tests passing.
|
||||
- [ ] Changes committed and pushed to the active branch.
|
||||
- [ ] Summary comment posted to the PR or Issue.
|
||||
- [ ] Mandatory disclosure line included at the end of the comment.
|
||||
@@ -0,0 +1,125 @@
|
||||
---
|
||||
name: github-implement
|
||||
description: Implement code changes from an approved issue plan, run monorepo validation, and create a pull request.
|
||||
---
|
||||
|
||||
# GitHub Implement Skill
|
||||
|
||||
Use this skill when an issue receives the `/implement` command.
|
||||
|
||||
## Overview
|
||||
|
||||
This skill guides the implementation of approved design plans. It enforces repository rules, executes automated validation, and prepares pull requests for the `next` branch.
|
||||
|
||||
## Procedural Workflow
|
||||
|
||||
### Phase 1: Context Ingestion
|
||||
|
||||
1. Read the complete issue description and title.
|
||||
2. Locate the approved implementation plan in the issue comments.
|
||||
3. Parse additional instructions from the `/implement` comment.
|
||||
4. If requirements conflict or miss critical details, stop and request clarification.
|
||||
|
||||
### Phase 2: Code Implementation
|
||||
|
||||
Apply all modifications according to `GEMINI.md` conventions:
|
||||
|
||||
1. **TypeScript Constraints**:
|
||||
- Enable strict typing for all new code.
|
||||
- Do not use the `any` type.
|
||||
- Do not use type assertions (`as Type`).
|
||||
- Do not use the non-null assertion operator (`!`).
|
||||
- Use explicit type guards or helper functions such as `castRef`.
|
||||
- Use `import type` for type-only imports.
|
||||
- Define object structures with `interface`, not `type` aliases.
|
||||
|
||||
2. **Documentation Rules**:
|
||||
- Add JSDoc comments to all exported functions, interfaces, and types.
|
||||
- Include clear description text in every JSDoc block.
|
||||
|
||||
3. **Component Architecture**:
|
||||
- Place components in dedicated directories under `packages/ui/src/components/<ComponentName>/`.
|
||||
- Provide `<ComponentName>.tsx` for component logic.
|
||||
- Provide `<ComponentName>.stories.tsx` for Storybook stories.
|
||||
- Provide `<ComponentName>.test.tsx` for Vitest tests.
|
||||
- Use `cva` for component variant management.
|
||||
- Merge CSS utility classes with `cn(...)` from `@ermnvldmr/stl`.
|
||||
- Use React Aria hooks and Radix UI primitives for accessible controls.
|
||||
|
||||
4. **Monorepo Imports and State**:
|
||||
- Use relative paths within the same package.
|
||||
- Do not use self-referential package names.
|
||||
- Use standard React state primitives. Do not add unapproved state managers.
|
||||
|
||||
5. **Protected Boundaries**:
|
||||
- Do not modify `.env.keys`, `pnpm-lock.yaml`, or `LICENSE`.
|
||||
- Do not edit content files in `services/docs/content/` or `services/www/content/` unless explicitly instructed.
|
||||
|
||||
### Phase 3: Monorepo Verification & Self-Correction
|
||||
|
||||
Run validation commands in strict sequence:
|
||||
|
||||
1. Run `pnpm typecheck`. Ensure zero compiler errors.
|
||||
2. Run `pnpm lint`. Ensure zero warnings and zero errors.
|
||||
3. Run `pnpm test`. Ensure all unit and component tests pass.
|
||||
4. Run `pnpm build`. Ensure clean compilation across all packages.
|
||||
|
||||
**Iterative Self-Correction Loop**:
|
||||
- If any check fails, inspect the diagnostic output.
|
||||
- Identify the root cause.
|
||||
- Apply targeted fixes adhering to all code rules.
|
||||
- Re-run the verification sequence from step 1.
|
||||
- Repeat until all four checks pass completely.
|
||||
|
||||
### Phase 4: Commit & Pull Request Preparation
|
||||
|
||||
1. **Commit Message**:
|
||||
- Format commits according to Conventional Commits: `<type>: implement issue #<number> (<title>)`.
|
||||
- Example: `feat: implement issue #42 (add theme toggle)`.
|
||||
|
||||
2. **Pull Request Target**:
|
||||
- Set base branch to `next`.
|
||||
|
||||
3. **Pull Request Body**:
|
||||
- Link the issue: `Resolves #<number>`.
|
||||
- Provide a concise summary of changes.
|
||||
- Detail the implementation walkthrough.
|
||||
- List the executed verification checks.
|
||||
- Append the mandatory attribution line.
|
||||
|
||||
4. **Mandatory Attribution**:
|
||||
- Conclude all PR bodies and issue comments with:
|
||||
`Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.`
|
||||
|
||||
## Pull Request Template
|
||||
|
||||
```markdown
|
||||
## Summary
|
||||
Resolves #<number>
|
||||
|
||||
<Brief explanation of the implemented feature or fix>
|
||||
|
||||
## Walkthrough of Changes
|
||||
- `<package-or-path>`: <Description of specific change>
|
||||
- `<package-or-path>`: <Description of specific change>
|
||||
|
||||
## Verification Results
|
||||
- [x] `pnpm typecheck` passed (0 errors)
|
||||
- [x] `pnpm lint` passed (0 warnings)
|
||||
- [x] `pnpm test` passed (all tests green)
|
||||
- [x] `pnpm build` passed (clean build)
|
||||
|
||||
Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.
|
||||
```
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
- [ ] Issue context, approved plan, and user instructions are satisfied.
|
||||
- [ ] TypeScript strict mode rules are respected (`no any`, `no as`, `no !`).
|
||||
- [ ] Exported symbols include JSDoc comments.
|
||||
- [ ] UI components reside in dedicated folders with tests and stories.
|
||||
- [ ] Monorepo boundaries and relative imports are respected.
|
||||
- [ ] All four verification checks passed cleanly.
|
||||
- [ ] Target branch is set to `next`.
|
||||
- [ ] PR description includes `Resolves #<number>`.
|
||||
- [ ] Mandatory attribution line is present.
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
name: github-plan
|
||||
description: Analyze an issue thread, iterate on feedback, and produce or update an implementation plan for ermnvldmr.com.
|
||||
---
|
||||
|
||||
# GitHub Issue Planning Skill (ASD-STE100 Standard)
|
||||
|
||||
## Overview
|
||||
|
||||
Use this skill when an issue receives the `/plan [optional instructions]` command.
|
||||
|
||||
This skill creates or updates an implementation plan before code modification starts. All outputs must follow ASD-STE100 language constraints and repository standards.
|
||||
|
||||
---
|
||||
|
||||
## ASD-STE100 Writing Rules
|
||||
|
||||
Follow these rules for all generated plans and documentation:
|
||||
|
||||
| Rule | Limit | Approved Example | Non-Approved Example |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **Procedural Sentences** | Max **20 words** | "Run `pnpm test`. Verify that all unit tests pass." | "You should run the pnpm test command to verify that all the unit tests pass properly without errors." |
|
||||
| **Descriptive Sentences** | Max **25 words** | "The `Button` component uses `cva` to manage style variants." | "The Button component is implemented using the cva library because it helps us manage complex style variants across different themes easily." |
|
||||
| **Voice** | **Active voice** | "The function validates the user input." | "The user input is validated by the function." |
|
||||
| **Mood and Tense** | **Present tense** and **Imperative mood** | "Click **Submit**. The form transmits the data." | "You will click submit and the form will be transmitting the data." |
|
||||
| **Noun Clusters** | Max **3 nouns** | "Theme configuration file" | "Theme variant style configuration file" |
|
||||
|
||||
### Controlled Vocabulary Guidelines
|
||||
- Do not use conversational filler (for example: "basically", "let's dive in", "simply", "feel free to").
|
||||
- Use approved verbs: use *use* (not *utilize*), *stop* (not *terminate*), *start* (not *initiate*), *show* (not *exhibit*).
|
||||
- Use clear and literal technical terms.
|
||||
|
||||
---
|
||||
|
||||
## Planning Responsibilities
|
||||
|
||||
### 1. Ingest Full Issue Context
|
||||
- Read the issue title, issue description, and all subsequent comments.
|
||||
- Identify user requirements, technical constraints, and reported symptoms.
|
||||
- Inspect relevant source files in the repository before proposing changes.
|
||||
- Read `GEMINI.md` to confirm current project conventions.
|
||||
|
||||
### 2. Multi-Turn Plan Iteration
|
||||
- Check if an earlier implementation plan exists in the issue thread.
|
||||
- If an earlier plan exists:
|
||||
- Do not create a plan from zero.
|
||||
- Retain approved architectural decisions from previous turns.
|
||||
- Apply the requested modifications or additions from the latest comment.
|
||||
- Summarize the specific adjustments made to the previous plan.
|
||||
- If no earlier plan exists:
|
||||
- Create a new baseline implementation plan from the issue requirements.
|
||||
|
||||
### 3. Enforce Repository Architecture (`GEMINI.md`)
|
||||
Every proposed plan must comply with repository architecture:
|
||||
- **Build System**: Use Rsbuild and Rspack. Do not propose Vite, Webpack, or Next.js.
|
||||
- **Strict TypeScript**:
|
||||
- Do not use `any`.
|
||||
- Do not use type assertions (`as Type`). Use type guards or `castRef` from `@ermnvldmr/stl`.
|
||||
- Do not use non-null assertions (`!`).
|
||||
- Use `import type` for type-only imports.
|
||||
- Define object shapes with `interface`, not `type` aliases.
|
||||
- Require JSDoc comments on all exported symbols.
|
||||
- **Component Architecture** (`packages/ui`):
|
||||
- Place components in `packages/ui/src/components/<ComponentName>/`.
|
||||
- Provide `<ComponentName>.tsx`, `<ComponentName>.stories.tsx`, and `<ComponentName>.test.tsx`.
|
||||
- Use `cva` for variant definitions.
|
||||
- Merge class names with `cn(...)` from `@ermnvldmr/stl`.
|
||||
- **Accessibility & State**:
|
||||
- Use React Aria hooks (`useButton`, `useFocusRing`, `useHover`) and Radix UI primitives.
|
||||
- Use standard React state (`useState`, `useReducer`, `useContext`) and `react-stately`.
|
||||
- Do not introduce external state management libraries.
|
||||
- **Monorepo Import Rules**:
|
||||
- Use relative import paths within the same package.
|
||||
- Do not import `@ermnvldmr/<package>` inside `<package>` itself.
|
||||
- **Protected Files**:
|
||||
- Do not modify `.env.keys`, `pnpm-lock.yaml`, `LICENSE`, `services/docs/content/`, or `services/www/content/`.
|
||||
|
||||
---
|
||||
|
||||
## Output Plan Structure
|
||||
|
||||
Format the generated plan with the following markdown template:
|
||||
|
||||
```markdown
|
||||
### Goal
|
||||
[Describe the objective in 1-2 sentences. Keep each sentence under 25 words.]
|
||||
|
||||
### Architecture & Technical Decisions
|
||||
- [Decision 1: Explain pattern, primitive, or component structure.]
|
||||
- [Decision 2: Explain typing or API contracts.]
|
||||
- [Decision 3: Explain state management or accessibility integration.]
|
||||
|
||||
### File Changes
|
||||
- `[NEW]` `packages/ui/src/components/NewComponent/NewComponent.tsx` - [Purpose]
|
||||
- `[NEW]` `packages/ui/src/components/NewComponent/NewComponent.stories.tsx` - [Purpose]
|
||||
- `[NEW]` `packages/ui/src/components/NewComponent/NewComponent.test.tsx` - [Purpose]
|
||||
- `[MODIFY]` `packages/ui/src/index.ts` - [Export new component]
|
||||
|
||||
### Verification Plan
|
||||
1. `pnpm typecheck` - Verify zero TypeScript compiler errors.
|
||||
2. `pnpm lint` - Verify zero ESLint warnings and errors.
|
||||
3. `pnpm test` - Run unit and integration tests.
|
||||
4. `pnpm build` - Run full workspace build.
|
||||
|
||||
### Open Questions
|
||||
- [List open questions or ambiguities. If no open questions exist, write "None.".]
|
||||
|
||||
Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common Traps and Solutions
|
||||
|
||||
| Anti-Pattern | Correct Action |
|
||||
| :--- | :--- |
|
||||
| Regenerating a new plan after user feedback | Update the existing plan and highlight modified sections. |
|
||||
| Using `as Type` assertions in the proposed code | Propose explicit type guards or `castRef` helpers. |
|
||||
| Missing Storybook or Vitest files for UI components | Include `.stories.tsx` and `.test.tsx` in the file plan. |
|
||||
| Proposing external state libraries | Use React 19 primitives and `react-stately`. |
|
||||
| Omitting the attribution line | Append the mandatory disclosure line at the end. |
|
||||
|
||||
---
|
||||
|
||||
## Verification Checklist
|
||||
|
||||
Before posting the plan response, verify all items:
|
||||
|
||||
- [ ] The issue thread context and all user comments are analyzed.
|
||||
- [ ] Existing plans are updated rather than replaced from scratch.
|
||||
- [ ] Proposed code satisfies all `GEMINI.md` constraints (`strict: true`, no `any`, no `as`, no `!`).
|
||||
- [ ] All UI components include unit tests and Storybook stories.
|
||||
- [ ] All sentences follow ASD-STE100 limits (<=20 words for instructions, <=25 words for descriptions).
|
||||
- [ ] Active voice is used throughout the plan.
|
||||
- [ ] The output concludes with: `Disclosure: I'm an AI assistant helping deytenit; I'm not deytenit.`
|
||||
|
||||
Reference in new issue
Block a user