mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-05-15 14:23:02 -07:00
feat(ux): finalize slash commands and resolve skill conflict discovery
This commit is contained in:
Keith Guerin
@@ -35,6 +35,8 @@ Follow these steps to create a GitHub issue:
|
||||
- If using a Markdown template, follow its structure exactly.
|
||||
- **Default Label**: Always include the `🔒 maintainer only` label unless the
|
||||
user explicitly requests otherwise.
|
||||
- **UX Epic Link**: Always append a reference to the main UX Epic to the end of the issue body (or within "Additional context"):
|
||||
`Epic: https://github.com/google-gemini/maintainers-gemini-cli/issues/1607`
|
||||
|
||||
5. **Create Issue**: Use the `gh` CLI to create the issue.
|
||||
- **CRITICAL:** To avoid shell escaping and formatting issues with
|
||||
|
||||
@@ -235,15 +235,8 @@ async function restartAction(
|
||||
);
|
||||
|
||||
if (failures.length < extensionsToRestart.length) {
|
||||
try {
|
||||
await context.services.agentContext?.config.reloadSkills();
|
||||
await context.services.agentContext?.config.getAgentRegistry()?.reload();
|
||||
} catch (error) {
|
||||
context.ui.addItem({
|
||||
type: MessageType.ERROR,
|
||||
text: `Failed to reload skills or agents: ${getErrorMessage(error)}`,
|
||||
});
|
||||
}
|
||||
// Note: reloadSkills and agentRegistry.reload are handled by the ExtensionLoader
|
||||
// during the restart process.
|
||||
}
|
||||
|
||||
if (failures.length > 0) {
|
||||
|
||||
@@ -18,6 +18,7 @@ export class SkillManager {
|
||||
private skills: SkillDefinition[] = [];
|
||||
private activeSkillNames: Set<string> = new Set();
|
||||
private adminSkillsEnabled = true;
|
||||
private pendingWarnings: Set<string> = new Set();
|
||||
|
||||
/**
|
||||
* Clears all discovered skills.
|
||||
@@ -50,6 +51,7 @@ export class SkillManager {
|
||||
isTrusted: boolean = false,
|
||||
): Promise<void> {
|
||||
this.clearSkills();
|
||||
this.pendingWarnings.clear();
|
||||
|
||||
// 1. Built-in skills (lowest precedence)
|
||||
await this.discoverBuiltinSkills();
|
||||
@@ -76,19 +78,27 @@ export class SkillManager {
|
||||
debugLogger.debug(
|
||||
'Workspace skills disabled because folder is not trusted.',
|
||||
);
|
||||
return;
|
||||
} else {
|
||||
const projectSkills = await loadSkillsFromDir(
|
||||
storage.getProjectSkillsDir(),
|
||||
);
|
||||
this.addSkillsWithPrecedence(projectSkills);
|
||||
|
||||
// 4.1 Workspace agent skills alias (.agents/skills)
|
||||
const projectAgentSkills = await loadSkillsFromDir(
|
||||
storage.getProjectAgentSkillsDir(),
|
||||
);
|
||||
this.addSkillsWithPrecedence(projectAgentSkills);
|
||||
}
|
||||
|
||||
const projectSkills = await loadSkillsFromDir(
|
||||
storage.getProjectSkillsDir(),
|
||||
);
|
||||
this.addSkillsWithPrecedence(projectSkills);
|
||||
this.emitPendingWarnings();
|
||||
}
|
||||
|
||||
// 4.1 Workspace agent skills alias (.agents/skills)
|
||||
const projectAgentSkills = await loadSkillsFromDir(
|
||||
storage.getProjectAgentSkillsDir(),
|
||||
);
|
||||
this.addSkillsWithPrecedence(projectAgentSkills);
|
||||
private emitPendingWarnings(): void {
|
||||
for (const warning of this.pendingWarnings) {
|
||||
coreEvents.emitFeedback('warning', warning);
|
||||
}
|
||||
this.pendingWarnings.clear();
|
||||
}
|
||||
|
||||
/**
|
||||
@@ -112,6 +122,7 @@ export class SkillManager {
|
||||
*/
|
||||
addSkills(skills: SkillDefinition[]): void {
|
||||
this.addSkillsWithPrecedence(skills);
|
||||
this.emitPendingWarnings();
|
||||
}
|
||||
|
||||
private addSkillsWithPrecedence(newSkills: SkillDefinition[]): void {
|
||||
@@ -127,8 +138,7 @@ export class SkillManager {
|
||||
`Skill "${newSkill.name}" from "${newSkill.location}" is overriding the built-in skill.`,
|
||||
);
|
||||
} else {
|
||||
coreEvents.emitFeedback(
|
||||
'warning',
|
||||
this.pendingWarnings.add(
|
||||
`Skill conflict detected: "${newSkill.name}" from "${newSkill.location}" is overriding the same skill from "${existingSkill.location}".`,
|
||||
);
|
||||
}
|
||||
|
||||
@@ -263,10 +263,14 @@ describe('SimpleExtensionLoader', () => {
|
||||
vi.spyOn(loader, 'stopExtension');
|
||||
vi.spyOn(loader, 'startExtension');
|
||||
await loader.start(mockConfig);
|
||||
mockSkillsReload.mockClear();
|
||||
|
||||
await loader.restartExtension(activeExtension);
|
||||
expect(loader.stopExtension).toHaveBeenCalledWith(activeExtension);
|
||||
expect(loader.startExtension).toHaveBeenCalledWith(activeExtension);
|
||||
expect(mockSkillsReload).toHaveBeenCalledTimes(2);
|
||||
expect(loader.stopExtension).toHaveBeenCalledWith(activeExtension, true);
|
||||
expect(loader.startExtension).toHaveBeenCalledWith(activeExtension, true);
|
||||
// Reload is called once in restartExtension's finally block.
|
||||
// (The stopExtension and startExtension calls inside restartExtension are told to skip).
|
||||
expect(mockSkillsReload).toHaveBeenCalledOnce();
|
||||
});
|
||||
});
|
||||
});
|
||||
|
||||
@@ -46,7 +46,7 @@ export abstract class ExtensionLoader {
|
||||
await Promise.all(
|
||||
this.getExtensions()
|
||||
.filter((e) => e.isActive)
|
||||
.map(this.startExtension.bind(this)),
|
||||
.map((e) => this.startExtension(e)),
|
||||
);
|
||||
} finally {
|
||||
this.isStarting = false;
|
||||
@@ -62,7 +62,10 @@ export abstract class ExtensionLoader {
|
||||
* go through `maybeStartExtension` which will only start the extension if
|
||||
* extension reloading is enabled and the `config` object is initialized.
|
||||
*/
|
||||
protected async startExtension(extension: GeminiCLIExtension) {
|
||||
protected async startExtension(
|
||||
extension: GeminiCLIExtension,
|
||||
skipRefresh = false,
|
||||
) {
|
||||
if (!this.config) {
|
||||
throw new Error('Cannot call `startExtension` prior to calling `start`.');
|
||||
}
|
||||
@@ -107,7 +110,9 @@ export abstract class ExtensionLoader {
|
||||
this.startingCount = 0;
|
||||
this.startCompletedCount = 0;
|
||||
}
|
||||
await this.maybeRefreshMemories();
|
||||
if (!skipRefresh) {
|
||||
await this.maybeRefreshMemories();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -169,7 +174,10 @@ export abstract class ExtensionLoader {
|
||||
* extension if extension reloading is enabled and the `config` object is
|
||||
* initialized.
|
||||
*/
|
||||
protected async stopExtension(extension: GeminiCLIExtension) {
|
||||
protected async stopExtension(
|
||||
extension: GeminiCLIExtension,
|
||||
skipRefresh = false,
|
||||
) {
|
||||
if (!this.config) {
|
||||
throw new Error('Cannot call `stopExtension` prior to calling `start`.');
|
||||
}
|
||||
@@ -221,7 +229,9 @@ export abstract class ExtensionLoader {
|
||||
this.stoppingCount = 0;
|
||||
this.stopCompletedCount = 0;
|
||||
}
|
||||
await this.maybeRefreshMemories();
|
||||
if (!skipRefresh) {
|
||||
await this.maybeRefreshMemories();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -239,8 +249,14 @@ export abstract class ExtensionLoader {
|
||||
}
|
||||
|
||||
async restartExtension(extension: GeminiCLIExtension): Promise<void> {
|
||||
await this.stopExtension(extension);
|
||||
await this.startExtension(extension);
|
||||
this.isStarting = true;
|
||||
try {
|
||||
await this.stopExtension(extension, true);
|
||||
await this.startExtension(extension, true);
|
||||
} finally {
|
||||
this.isStarting = false;
|
||||
await this.maybeRefreshMemories();
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
@@ -9,42 +9,57 @@ underlying "rigor."
|
||||
|
||||
1. **Onboarding**: If this is a new session and the user seems new to the
|
||||
extension, perform these steps:
|
||||
- Silently check for and delete obsolete manual versions of `ux-git-workflow`, `ux-design`, `ux-writing`, or the old `ux-extension` versions in `~/.gemini/skills/`.
|
||||
- Ensure the extension is linked: `gemini extensions link ./packages/extensions/gemini-cli-ux`.
|
||||
- **MANDATORY**: Tell the user to reload the extension after linking or updating: _"Please run `/extensions reload gemini-cli-ux` to activate the new commands."_
|
||||
- Casually mention: _"I've loaded the `gemini-cli-ux` extension. To get started, just run `/ux:new-feature`."_
|
||||
- Silently check for and delete obsolete manual versions of `ux-git-skill`,
|
||||
`ux-designer`, `ux-writer`, or the old `ux-extension` versions in
|
||||
`~/.gemini/skills/`.
|
||||
- Ensure the extension is linked:
|
||||
`gemini extensions link ./packages/extensions/gemini-cli-ux`.
|
||||
- **MANDATORY**: Tell the user to reload the extension after linking or
|
||||
updating: _"Please run `/extensions reload gemini-cli-ux` to activate the
|
||||
new commands."_
|
||||
- Casually mention: _"I've loaded the `gemini-cli-ux` extension. To get
|
||||
started, just run `/ux-new-feature`."_
|
||||
2. **Intent Mapping**:
|
||||
- **User wants to start work**: Suggest: _"Let's use `/ux:new-feature`
|
||||
to create a fresh sibling folder for this."_
|
||||
- **User starts UI coding**: Suggest: _"I'll load `/frontend`. Want to use `/ux:design` to brainstorm the layout?"_
|
||||
- **User is writing text/copy**: Suggest: _"Let's run `/ux:write` to make sure our terminology matches the project rules."_
|
||||
- **User is ready to submit or hit a CI error**: Offer: _"Let's use `/ux:pr` to handle the submission protocol and fix any issues."_
|
||||
- **User wants to start work**: Suggest: _"Let's use `/ux-new-feature` to
|
||||
create a fresh sibling folder for this."_
|
||||
- **User starts UI coding**: Suggest: _"I'll load `/frontend`. Want to use
|
||||
`/ux-design` to brainstorm the layout?"_
|
||||
- **User is writing text/copy**: Suggest: _"Let's run `/ux-review` to make
|
||||
sure our terminology matches the project rules."_
|
||||
- **User is ready to submit or hit a CI error**: Offer: _"Let's use `/ux-pr`
|
||||
to handle the submission protocol and fix any issues."_
|
||||
3. **Educational Transparency**: When you perform a "mandatory" step (like
|
||||
`preflight` inside `/ux:pr`), explain it as a benefit to the user: _"I'm running the full
|
||||
preflight now to ensure everything is correct for review."_
|
||||
`preflight` inside `/ux-pr`), explain it as a benefit to the user: _"I'm
|
||||
running the full preflight now to ensure everything is correct for review."_
|
||||
|
||||
## 🚨 Standard Operating Procedures (Agent Only)
|
||||
|
||||
1. **Worktree Strategy**: ALWAYS use the `ux-git-workflow` skill for task isolation.
|
||||
1. **Worktree Strategy**: ALWAYS use the `ux-git-skill` skill for task
|
||||
isolation.
|
||||
2. **Diff Minimization**: ALWAYS minimize diffs. Never move code between files
|
||||
while making logic changes in the same step. Separate refactors
|
||||
(zero-modification moves) into their own commits before applying logic
|
||||
changes.
|
||||
3. **Submission Rigor**: ALWAYS use `/ux:pr` for final pushes. This
|
||||
includes running `/review-frontend` to perform an automated audit. Never
|
||||
push manually.
|
||||
4. **UI Review**: Use `ux-design` to audit components against the v1.0
|
||||
3. **Submission Rigor**: ALWAYS use `/ux-pr` for final pushes. This includes
|
||||
running `/review-frontend` to perform an automated audit. Never push
|
||||
manually.
|
||||
4. **UI Review**: Use `ux-designer` to audit components against the v1.0
|
||||
principles.
|
||||
5. **Remediation**: Use **`/ux:pr`** if CI checks fail on GitHub or if comments are received to
|
||||
initiate a systematic manager-worker fix loop.
|
||||
5. **Remediation**: Use **`/ux-pr`** if CI checks fail on GitHub or if comments
|
||||
are received to initiate a systematic manager-worker fix loop.
|
||||
6. **No Shortcuts**: Never use `--no-verify`. Protect the PR from CI failures.
|
||||
7. **Keep PRs Small**: ALWAYS aim for under 500 lines of code changed (excluding snapshots). If a task exceeds this limit, simplify the code, cut scope, or plan to split it into multiple PRs.
|
||||
7. **Keep PRs Small**: ALWAYS aim for under 500 lines of code changed
|
||||
(excluding snapshots). If a task exceeds this limit, simplify the code, cut
|
||||
scope, or plan to split it into multiple PRs.
|
||||
8. **Task Finality**: ALWAYS run `npm run build` or `npm run typecheck` to
|
||||
verify structural integrity before declaring any task as "complete".
|
||||
9. **Copyright Headers**: NEVER modify or update the copyright header comments
|
||||
(e.g., year) in existing files.
|
||||
|
||||
## Mandatory Workflow Triggers
|
||||
|
||||
- **Checkout**: Use `worktree-manager.sh pr <number>`.
|
||||
- **Address Feedback**: `ux-git-workflow` incorporates comment fetching natively now.
|
||||
- **Address Feedback**: `ux-git-skill` incorporates comment fetching natively
|
||||
now.
|
||||
|
||||
Remember: The user focuses on the **Vibe**, you handle the **Rigor**.
|
||||
|
||||
@@ -0,0 +1,79 @@
|
||||
# 🚀 Your UX "Vibe Coding" Command Center
|
||||
|
||||
Hey! Welcome to `gemini-cli-ux`. I'm here to handle the "rigor" of contributing
|
||||
to the Gemini CLI so you can focus on the "vibe" of your designs.
|
||||
|
||||
> **Important Developer Note:** To develop on this extension, **do not** use the
|
||||
> `install` command. Instead, run:
|
||||
> `gemini extensions link ./packages/extensions/gemini-cli-ux`
|
||||
>
|
||||
> This will symlink the source code, meaning any changes you make will be
|
||||
> instantly available the next time you launch the CLI, and you won't get
|
||||
> confusing "ghost file" conflicts!
|
||||
|
||||
We've simplified the entire contribution lifecycle into a **"Power Four"**
|
||||
command suite.
|
||||
|
||||
---
|
||||
|
||||
### **1. The Flow: Start Clean (`/ux-new-feature`)**
|
||||
|
||||
When you're ready to build something new or pick up an existing PR, run this. It
|
||||
triggers the **`ux-git-skill`** skill to:
|
||||
|
||||
- Create a fresh sibling folder for the task (Base Folder Strategy).
|
||||
- Keep your `main` branch pristine and avoid macOS sandbox interference issues.
|
||||
- Automatically run `npm install` so you're ready to code.
|
||||
|
||||
### **2. The Look: Vibe Coding (`/ux-design`)**
|
||||
|
||||
As soon as you touch React/Ink code, invoke your **`ux-designer`** partner.
|
||||
|
||||
- It helps you scaffold new components or audit your work against our v1.0
|
||||
principles: **Signal over Noise**, **Coherent State**, and **Intent
|
||||
Signaling**.
|
||||
- **Tip**: Use **`/introspect`** alongside it if you need me to explain how a
|
||||
specific part of the system works before we change it.
|
||||
|
||||
### **3. The Voice: Quality Copy (`/ux-review`)**
|
||||
|
||||
When you're adding labels, loading states, or errors, trigger the
|
||||
**`ux-writer`** expert.
|
||||
|
||||
- I'll make sure your strings are concise and match our project's specific
|
||||
terminology.
|
||||
|
||||
### **4. The Finisher: Submit & Feedback (`/ux-pr`)**
|
||||
|
||||
This is the "Loop Killer." When you're ready to merge or when a PR inevitably
|
||||
fails CI, run this to trigger the **`ux-git-skill`** submission protocol:
|
||||
|
||||
1. **Rebase & Verify**: Syncs with `main` and mandates
|
||||
`npm run build`/`typecheck`.
|
||||
2. **Snapshots**: Fixes snapshots for CI using a neutral environment
|
||||
(`TERM_PROGRAM=generic`).
|
||||
3. **Jacob's Protocol**: Ensures refactors (zero-modification moves) are
|
||||
strictly separated from logic changes in the commit history.
|
||||
4. **Feedback Loop**: If a PR exists, it automatically fetches inline comments
|
||||
and CI failure logs, generates a "Fix-it" checklist, and helps you resolve
|
||||
them locally before you push again.
|
||||
|
||||
---
|
||||
|
||||
### **⚡️ Quick Start: Build & Run**
|
||||
|
||||
To see your changes in action, use the new high-speed bundling process. This is
|
||||
significantly faster than the old `npm run build-and-start` method:
|
||||
|
||||
```bash
|
||||
# 1. Bundle your changes (FAST)
|
||||
npm run bundle
|
||||
|
||||
# 2. Run your local build
|
||||
node bundle/gemini.js
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**Ready to build?** Start with `/ux-new-feature` and tell me what's on your
|
||||
mind!
|
||||
@@ -0,0 +1,4 @@
|
||||
description = "Your UI architect partner. Use this to scaffold new React/Ink components or audit your existing UI against the v1.0 Design Principles."
|
||||
prompt = """
|
||||
Activate the `ux-designer` skill and help the user scaffold new UI components or audit existing ones against the principles of Signal over Noise, Coherent State, and Intent Signaling.
|
||||
"""
|
||||
@@ -0,0 +1,4 @@
|
||||
description = "Start a new feature or check out an existing PR. Creates a clean, isolated worktree and prepares your environment so you're immediately ready to code."
|
||||
prompt = """
|
||||
Activate the `ux-git-skill` skill and assist the user with creating a new branch or checking out an existing PR into a sibling worktree. Ensure all 'Phase 1' workflows (like npm install) are completed so they are ready to code.
|
||||
"""
|
||||
@@ -0,0 +1,4 @@
|
||||
description = "The loop killer. Handles the entire submission and feedback lifecycle: full preflight, safe rebase, snapshot updates, and fetching/resolving PR feedback."
|
||||
prompt = """
|
||||
Activate the `ux-git-skill` skill and execute the 'Phase 2: The PR Feedback Loop' protocols. If there is no PR, run the audits and submit. If a PR exists, fetch the latest comments/CI failures, create a checklist, and help the user resolve them.
|
||||
"""
|
||||
@@ -0,0 +1,4 @@
|
||||
description = "Your dedicated copy expert. Reviews user-facing strings and labels for clarity, brevity, and alignment with the CLI's terminology."
|
||||
prompt = """
|
||||
Activate the `ux-writer` skill and review the requested strings or files to ensure they match the project's tone and terminology rules.
|
||||
"""
|
||||
@@ -0,0 +1,4 @@
|
||||
description = "Display the UX Extension help and onboarding guide."
|
||||
prompt = """
|
||||
Please read the `packages/extensions/gemini-cli-ux/WELCOME.md` file and present its contents to the user. This serves as the main help guide, explaining the workflow and available commands for the UX extension.
|
||||
"""
|
||||
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"name": "gemini-cli-ux",
|
||||
"version": "1.0.0",
|
||||
"description": "Specialized suite of UX development tools for the Gemini CLI team. A Lifecycle Command Center providing workflow management, UI design scaffolding, and copy review.",
|
||||
"author": "AI DevTools UX Team",
|
||||
"skills": ["skills/ux-git-workflow", "skills/ux-design", "skills/ux-writing"],
|
||||
"commands": [
|
||||
"commands/ux-new-feature.toml",
|
||||
"commands/ux-pr.toml",
|
||||
"commands/ux-design.toml",
|
||||
"commands/ux-review.toml",
|
||||
"commands/ux.toml"
|
||||
]
|
||||
}
|
||||
+3
-2
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: _ux_finish-pr
|
||||
name: finish-pr
|
||||
description: Expert PR submission tool. Automates safe rebase, cross-platform snapshots, and mandatory full preflight validation.
|
||||
---
|
||||
|
||||
@@ -17,7 +17,7 @@ You are a senior co-author assistant. Your goal is to ensure this PR passes CI o
|
||||
### **2. Neutral Environment Snapshots**
|
||||
- **Action**: If UI files were modified, you MUST run tests with:
|
||||
```bash
|
||||
TERM_PROGRAM=none npm test -w @google/gemini-cli -- -u
|
||||
TERM_PROGRAM=generic npm test -w @google/gemini-cli -- -u
|
||||
```
|
||||
- **Reason**: This prevents macOS-specific icons (like `MAC_TERMINAL_ICON`) from leaking into snapshots, which causes CI failure on Linux runners.
|
||||
|
||||
@@ -26,6 +26,7 @@ You are a senior co-author assistant. Your goal is to ensure this PR passes CI o
|
||||
```bash
|
||||
npm run preflight
|
||||
```
|
||||
- **Verification**: Run `npm run typecheck` explicitly if `preflight` does not include it, to ensure cross-package integrity.
|
||||
- **Automated Audit**: You MUST run `/review-frontend <PR_NUMBER>` and address any issues found. This provides an automated audit of your changes to catch common mistakes before a maintainer review.
|
||||
- **Constraint**: Passing individual tests is NOT enough. `preflight` ensures `tsc --build` passes, catching TypeScript inference bugs that unit tests miss.
|
||||
- **TDD Fallback**: If `preflight` fails, you must create a local reproduction test before attempting a fix.
|
||||
+2
-2
@@ -1,5 +1,5 @@
|
||||
---
|
||||
name: _ux_git-worktree
|
||||
name: git-worktree
|
||||
description: Manage Git Worktrees according to the "Base Folder Strategy". Use when the user wants to create branches, switch tasks, check out PRs, or manage parallel development environments.
|
||||
---
|
||||
|
||||
@@ -29,7 +29,7 @@ When the user asks to "start a new task" or "create a branch":
|
||||
|
||||
When the user asks to "check out PR #123":
|
||||
1. **NEVER** use standard `gh pr checkout` without a directory.
|
||||
2. **ALWAYS** use the automation script: `./packages/extensions/ux-toolkit/skills/_ux_git-worktree/scripts/worktree-manager.sh pr 123`.
|
||||
2. **ALWAYS** use the automation script: `./packages/extensions/extension/skills/git-worktree/scripts/worktree-manager.sh pr 123`.
|
||||
3. **Mandatory Prep**: Run `npm install` inside the new worktree directory to ensure all dependencies are resolved.
|
||||
4. This script will automatically fetch the PR title and create a semantic directory name (e.g., `pr-123-fix-core-bug`).
|
||||
|
||||
+5
-2
@@ -1,6 +1,9 @@
|
||||
---
|
||||
name: _ux_designer
|
||||
description: Expert UX Designer for Gemini CLI. Use to review React/Ink UI components, evaluate PRs, and ensure adherence to the v1.0 Design Principles (Signal over Noise, Coherent State, Intent Signaling, and Density).
|
||||
name: ux-designer
|
||||
description:
|
||||
Expert UX Designer for Gemini CLI. Use to review React/Ink UI components,
|
||||
evaluate PRs, and ensure adherence to the v1.0 Design Principles (Signal over
|
||||
Noise, Coherent State, Intent Signaling, and Density).
|
||||
---
|
||||
|
||||
# UX Designer (Gemini CLI)
|
||||
@@ -1,6 +1,9 @@
|
||||
---
|
||||
name: ux-git-workflow
|
||||
description: End-to-end PR lifecycle manager. Handles the "Base Folder Strategy" for worktrees, safe rebasing, Neutral Environment snapshots, preflight validation, and Jacob's Protocol for structured commits.
|
||||
name: ux-git-skill
|
||||
description:
|
||||
End-to-end PR lifecycle manager. Handles the "Base Folder Strategy" for
|
||||
worktrees, safe rebasing, Neutral Environment snapshots, preflight
|
||||
validation, and Jacob's Protocol for structured commits.
|
||||
---
|
||||
|
||||
# UX Git Workflow
|
||||
@@ -24,7 +27,7 @@ When the user asks to "start a new task" or "create a branch":
|
||||
1. Identify the base directory (the parent of `main/`).
|
||||
2. Use `git worktree add ../<branch-name> -b <branch-name>` from within `main/`.
|
||||
3. **Mandatory Prep**: Run `npm install` inside the new worktree directory to ensure all dependencies are resolved.
|
||||
4. Instruct the user to move into the new directory and reload their session.
|
||||
4. **User Handoff & Education**: Instruct the user to move into the new directory, reload their session, and test their branch using the new fast build method: `npm run bundle; node bundle/gemini.js` (which replaces the slower `npm run build-and-start`).
|
||||
|
||||
#### 2. Checking out a PR (Semantic Naming)
|
||||
When the user asks to "check out PR #123":
|
||||
@@ -116,6 +119,7 @@ If operating in a sibling worktree (e.g., `feature-xyz/`):
|
||||
- Link the issue in the PR description (e.g., `Fixes #<number>`).
|
||||
4. If **NO** high-confidence match is found:
|
||||
- Create a new issue using `gh issue create` detailing the bug or feature.
|
||||
- **UX Epic Link**: The new issue's description MUST include a reference to the main UX Epic: `Epic: https://github.com/google-gemini/maintainers-gemini-cli/issues/1607`.
|
||||
- Assign it to the user and link it in the PR description.
|
||||
5. **Project Board Requirement**: You MUST ensure the chosen or created issue is added to the UX engineering board.
|
||||
- Add it to the project: `gh project item-add 33 --owner google-gemini --url <issue-url>` (Targeting: https://github.com/orgs/google-gemini/projects/33/views/5).
|
||||
@@ -129,7 +133,7 @@ If operating in a sibling worktree (e.g., `feature-xyz/`):
|
||||
- **Action**: Use `git rebase -i` or `git reset --soft` to organize commits into these tiers. Ensure refactors are ALWAYS isolated from logic.
|
||||
- **Push**: `git push origin HEAD --force-with-lease`.
|
||||
- **Draft PR**: If creating a new PR, you MUST create it as a draft by default (e.g., `gh pr create --draft`).
|
||||
- **Link**: You MUST provide the full, clickable GitHub PR link (e.g., `https://github.com/google-gemini/gemini-cli/pull/23487`) as the final output of this skill. This allows the user to immediately verify the update.
|
||||
- **MANDATORY FINAL OUTPUT**: You MUST provide the full, clickable **GitHub PR link** (e.g., `https://github.com/google-gemini/gemini-cli/pull/23487`) AND the **Issue URL** (e.g., `https://github.com/google-gemini/gemini-cli/issues/12345`) as the final output of this skill. This allows the user to immediately verify the update and track the associated task.
|
||||
|
||||
#### 10. CI Verification & Remediation Loop (The Slog)
|
||||
- **Context**: Getting PRs ready for review is typically a "slog" due to CI checks failing in the GitHub environment even after passing local presubmit tests.
|
||||
|
||||
+5
-5
@@ -1,10 +1,10 @@
|
||||
---
|
||||
name: _ux_string-reviewer
|
||||
description: >
|
||||
Use this skill when asked to review text and user-facing strings within the codebase. It ensures that these strings follow rules on clarity,
|
||||
usefulness, brevity and style.
|
||||
name: ux-writer
|
||||
description:
|
||||
Use this skill when asked to review text and user-facing strings within the
|
||||
codebase. It ensures that these strings follow rules on clarity, usefulness,
|
||||
brevity and style.
|
||||
---
|
||||
|
||||
# String Reviewer
|
||||
|
||||
## Instructions
|
||||
@@ -1,50 +0,0 @@
|
||||
# UX Extension: Global Toolbox Context
|
||||
|
||||
You are a **UX Engineering Peer**. Your goal is to guide the user through the
|
||||
Gemini CLI contribution process casually and effectively, ensuring their
|
||||
"intent" reaches the finish line without them having to worry about the
|
||||
underlying "rigor."
|
||||
|
||||
## 🚀 Proactive Guidance Rules
|
||||
|
||||
1. **Onboarding**: If this is a new session and the user seems new to the
|
||||
extension, casually mention: _"I've updated your local extension. To get
|
||||
started, run `/_ux_help`."_
|
||||
2. **Intent Mapping**:
|
||||
- **User wants to start work**: Suggest: _"Should we use `_ux_git-worktree`
|
||||
to create a fresh sibling folder for this?"_
|
||||
- **User starts UI coding**: Suggest: _"I'll load `/frontend`. Sound good?"_
|
||||
- **User is ready to submit**: Offer: _"Ready to cross the finish line? I'll
|
||||
handle the `/_ux_finish-pr` protocol."_
|
||||
- **User receives feedback**: Suggest: _"I'll use `pr-address-comments` to
|
||||
summarize the feedback into a checklist for us."_
|
||||
3. **Educational Transparency**: When you perform a "mandatory" step (like
|
||||
`preflight`), explain it as a benefit to the user: _"I'm running the full
|
||||
preflight now to ensure everything is correct for review."_
|
||||
|
||||
## 🚨 Standard Operating Procedures (Agent Only)
|
||||
|
||||
1. **Worktree Strategy**: ALWAYS use `_ux_git-worktree` for task isolation.
|
||||
2. **Diff Minimization**: ALWAYS minimize diffs. Never move code between files
|
||||
while making logic changes in the same step. Separate refactors
|
||||
(zero-modification moves) into their own commits before applying logic
|
||||
changes.
|
||||
3. **Submission Rigor**: ALWAYS use `/_ux_finish-pr` for final pushes. This
|
||||
includes running `/review-frontend` to perform an automated audit. Never
|
||||
push manually.
|
||||
4. **UI Review**: Use `_ux_designer` to audit components against the v1.0
|
||||
principles.
|
||||
5. **Remediation**: Use **`/review-and-fix`** if CI checks fail on GitHub to
|
||||
initiate a systematic manager-worker fix loop.
|
||||
6. **No Shortcuts**: Never use `--no-verify`. Protect the PR from CI failures.
|
||||
7. **Task Finality**: ALWAYS run `npm run build` or `npm run typecheck` to
|
||||
verify structural integrity before declaring any task as "complete".
|
||||
|
||||
## Mandatory Workflow Triggers
|
||||
|
||||
- **Checkout**: Use `worktree-manager.sh pr <number>`.
|
||||
- **Address Feedback**: Use `activate_skill pr-address-comments`.
|
||||
- **Systematic Fix**: Use `activate_skill ruthless-refactorer` (via
|
||||
`/review-and-fix`).
|
||||
|
||||
Remember: The user focuses on the **Vibe**, you handle the **Rigor**.
|
||||
@@ -1,73 +0,0 @@
|
||||
# 🚀 Your UX "Vibe Coding" Guide
|
||||
|
||||
Hey! Welcome to the UX Team's global toolbox. I'm here to handle the "rigor" of
|
||||
contributing to the Gemini CLI so you can focus on the "vibe" of your designs.
|
||||
|
||||
> **Important Developer Note:** To develop on this extension, **do not** use the
|
||||
> `install` command. Instead, run:
|
||||
> `gemini extensions link ./packages/extensions/ux-extension`
|
||||
>
|
||||
> This will symlink the source code, meaning any changes you make will be
|
||||
> instantly available the next time you launch the CLI, and you won't get
|
||||
> confusing "ghost file" conflicts!
|
||||
|
||||
Here is our end-to-end flow for building and shipping high-quality features:
|
||||
|
||||
---
|
||||
|
||||
### **Phase 1: Start Clean**
|
||||
|
||||
When you're ready to build something new, just tell me. I'll use
|
||||
**`_ux_git-worktree`** to create a fresh sibling folder for the task. This keeps
|
||||
your `main` branch pristine and avoids those annoying macOS sandbox interference
|
||||
issues.
|
||||
|
||||
### **Phase 2: Vibe Coding (Prototyping)**
|
||||
|
||||
As soon as we touch UI code, I'll offer to load **`/frontend`**. This gives me
|
||||
the full context of our React component library and the
|
||||
`Strict Development Rules` (like using our custom `waitFor` and avoiding `any`).
|
||||
|
||||
- **Tip**: Use **`/introspect`** if you need me to explain how a specific part
|
||||
of the system works before we change it.
|
||||
|
||||
### **Phase 3: Quality Audit**
|
||||
|
||||
Before we finish, we'll run a few checks:
|
||||
|
||||
1. **`_ux_designer`**: I'll audit your work against our v1.0 principles:
|
||||
**Signal over Noise**, **Coherent State**, and **Intent Signaling**.
|
||||
2. **`_ux_string-reviewer`**: I'll make sure your labels and tips match our
|
||||
project's specific terminology.
|
||||
|
||||
### **Phase 4: Crossing the Finish Line**
|
||||
|
||||
When you're happy, just say "I'm ready to submit." I'll run the
|
||||
**`/_ux_finish-pr`** command. It handles:
|
||||
|
||||
1. **Rebase**: Syncs with `main`.
|
||||
2. **Verification**: Mandatory `npm run build` or `npm run typecheck` to ensure
|
||||
structural integrity.
|
||||
3. **Snapshots**: Fixes snapshots for CI using a neutral environment.
|
||||
4. **Preflight**: Runs the full `preflight` suite.
|
||||
5. **Commit Strategy**: Squashes your main feature and ALL previous review
|
||||
fixes into one commit, but keeps only the **very last** round of code review
|
||||
comments as separate commits. This keeps the diffs manageable and fast for
|
||||
reviewers (30 seconds vs. 10 minutes).
|
||||
|
||||
### **Phase 5: Handling Feedback**
|
||||
|
||||
If a maintainer (or Jacob) leaves comments, I've got you covered:
|
||||
|
||||
1. **`pr-address-comments`**: I'll fetch every comment (including nested inline
|
||||
ones), create a checklist, and help you address them one by one. I'll also
|
||||
post direct replies to every addressed comment to keep the reviewer
|
||||
informed.
|
||||
2. **`/review-and-fix`**: If the CI checks fail on GitHub, I'll use this to
|
||||
systematically diagnose and fix the specific failures using a manager-worker
|
||||
loop.
|
||||
|
||||
---
|
||||
|
||||
**Need a refresher?** Just type `/_ux_help` anytime. **Ready to build?** Tell me
|
||||
what's on your mind!
|
||||
@@ -1,4 +0,0 @@
|
||||
description = "Show the UX Contribution Guide and workflow overview."
|
||||
prompt = """
|
||||
Read the guide at `packages/extensions/ux-extension/WELCOME.md` and output its contents to the user.
|
||||
"""
|
||||
@@ -1,19 +0,0 @@
|
||||
{
|
||||
"name": "ux-extension",
|
||||
"version": "1.0.0",
|
||||
"description": "Specialized suite of UX development tools for the Gemini CLI team, including worktree management, PR finishing, and design auditing.",
|
||||
"author": "AI DevTools UX Team",
|
||||
"skills": [
|
||||
"skills/_ux_git-worktree",
|
||||
"skills/_ux_finish-pr",
|
||||
"skills/_ux_designer",
|
||||
"skills/_ux_string-reviewer"
|
||||
],
|
||||
"commands": [
|
||||
"commands/_ux_help.toml",
|
||||
"commands/_ux_finish-pr.toml",
|
||||
"commands/_ux_git-worktree.toml",
|
||||
"commands/_ux_designer.toml",
|
||||
"commands/_ux_string-reviewer.toml"
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user