Merge branch 'next' into kimi-runtime-support
This commit is contained in:
Viktorplus
@@ -806,7 +806,7 @@ The migration-specific ownership and source snapshots live in
|
||||
| Codex | `~/.codex` | `./.codex` | `skills/gsd-*/SKILL.md` | `agents/` source markdown plus per-agent TOML | `config.toml` `[agents.gsd-*]`, `[features].hooks` (canonical; legacy alias `codex_hooks` is recognized and migrated forward on reinstall, #3566), and hook tables |
|
||||
| GitHub Copilot | `~/.copilot` | `./.github` | `skills/gsd-*/SKILL.md`, `copilot-instructions.md`, and `AGENTS.md` (repo root, local) | `.agent.md` files | Self-contained `sessionStart` hook (`hooks/gsd-session.json`, inline `command` type); no statusline |
|
||||
| Antigravity | auto-detected: `~/.gemini/antigravity`, `~/.gemini/antigravity-ide`, or `~/.gemini/antigravity-cli` | `./.agent` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | Gemini-style `settings.json` hook entries when installed by GSD |
|
||||
| Cursor | `~/.cursor` | `./.cursor` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | Rule references under `rules/`; no GSD hooks |
|
||||
| Cursor | `~/.cursor` | `./.cursor` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | Rule references under `rules/`; `hooks.json` with sessionStart context injection and postToolUse STATE.md monitor (#777) |
|
||||
| Windsurf | `~/.codeium/windsurf` | `./.windsurf` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | Rule references under `rules/`; no GSD hooks |
|
||||
| Augment Code | `~/.augment` | `./.augment` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | No GSD hooks or statusline |
|
||||
| Trae | `~/.trae` | `./.trae` | `skills/gsd-*/SKILL.md` | `agents/gsd-*.md` | Rule references under `rules/`; no GSD hooks |
|
||||
|
||||
@@ -1148,11 +1148,13 @@ Update GSD with changelog preview, and optionally sync skills or reapply local p
|
||||
|------|-------------|
|
||||
| `--sync` | Sync skills from the GSD registry after updating |
|
||||
| `--reapply` | Restore local modifications (patches) after updating |
|
||||
| `--next` / `--rc` | Target the `@next` RC dist-tag instead of `@latest` (installs or refreshes a release candidate, e.g. `1.4.0-rc.1`; see ADR #660) |
|
||||
|
||||
```bash
|
||||
/gsd-update # Check for updates and install
|
||||
/gsd-update --sync # Update and sync skills
|
||||
/gsd-update --reapply # Update and reapply local patches
|
||||
/gsd-update --next # Install from the @next RC dist-tag
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
@@ -904,6 +904,7 @@ continues. Drift detection cannot fail verification.
|
||||
- REQ-UPDATE-03: System MUST be runtime-aware and target the correct directory
|
||||
- REQ-UPDATE-04: System MUST back up locally modified files to `gsd-local-patches/`
|
||||
- REQ-UPDATE-05: `/gsd-update --reapply` MUST restore local modifications after update
|
||||
- REQ-UPDATE-06: `/gsd-update --next` (alias `--rc`) MUST target the `@next` RC dist-tag for version check and install; omitting the flag MUST keep `@latest` behavior unchanged (ADR #660)
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -359,7 +359,10 @@
|
||||
"hooks": [
|
||||
"gsd-check-update-worker.js",
|
||||
"gsd-check-update.js",
|
||||
"gsd-config-reload.js",
|
||||
"gsd-context-monitor.js",
|
||||
"gsd-cursor-post-tool.js",
|
||||
"gsd-cursor-session-start.js",
|
||||
"gsd-graphify-update.sh",
|
||||
"gsd-phase-boundary.sh",
|
||||
"gsd-prompt-guard.js",
|
||||
|
||||
@@ -471,7 +471,7 @@ Full listing: `gsd-core/bin/lib/*.cjs`.
|
||||
|
||||
---
|
||||
|
||||
## Hooks (14 shipped)
|
||||
## Hooks (17 shipped)
|
||||
|
||||
Full listing: `hooks/`.
|
||||
|
||||
@@ -482,11 +482,14 @@ Full listing: `hooks/`.
|
||||
| `gsd-check-update.js` | `SessionStart` | Background check for new GSD versions |
|
||||
| `gsd-check-update-worker.js` | (worker) | Background worker helper for check-update |
|
||||
| `gsd-update-banner.js` | `SessionStart` | Opt-in banner surfacing update availability when GSD statusline isn't used (PR #2795) |
|
||||
| `gsd-cursor-session-start.js` | Cursor `sessionStart` | Cursor-native context injection at session start (issue #777) |
|
||||
| `gsd-cursor-post-tool.js` | Cursor `postToolUse` | Cursor-native STATE.md update monitor after tool calls (issue #777) |
|
||||
| `gsd-prompt-guard.js` | `PreToolUse` | Scans `.planning/` writes for prompt-injection patterns (advisory) |
|
||||
| `gsd-workflow-guard.js` | `PreToolUse` | Detects file edits outside GSD workflow context (advisory, opt-in) |
|
||||
| `gsd-read-guard.js` | `PreToolUse` | Advisory guard preventing Edit/Write on unread files |
|
||||
| `gsd-read-injection-scanner.js` | `PostToolUse` | Scans tool Read results for prompt-injection patterns (v1.36+, PR #2201) |
|
||||
| `gsd-worktree-path-guard.js` | `PreToolUse` | Hard-blocks Edit/Write/MultiEdit with absolute paths outside the worktree root (PR #579, #260) |
|
||||
| `gsd-config-reload.js` | `FileChanged` | Hot-reloads GSD config context when `.planning/config.json` changes mid-session (#770) |
|
||||
| `gsd-session-state.sh` | `PostToolUse` | Session-state tracking for shell-based runtimes |
|
||||
| `gsd-validate-commit.sh` | `PostToolUse` | Commit validation for conventional-commit enforcement |
|
||||
| `gsd-phase-boundary.sh` | `PostToolUse` | Phase-boundary detection for workflow transitions |
|
||||
|
||||
@@ -16,6 +16,7 @@ Language versions: [English](README.md) · [Português (pt-BR)](pt-BR/README.md)
|
||||
## How-to guides
|
||||
|
||||
- [Install on your runtime](how-to/install-on-your-runtime.md) — runtime-specific install steps for all 15 supported runtimes
|
||||
- [Install a minimal GSD and add skills later](how-to/install-minimal-and-add-skills.md) — install only the core skills, then grow the surface with profiles and `/gsd:surface`
|
||||
- [Discuss a phase](how-to/discuss-a-phase.md) — capture implementation decisions before planning begins
|
||||
- [Plan a phase](how-to/plan-a-phase.md) — run research, decompose work, and verify plan quality
|
||||
- [Execute a phase](how-to/execute-a-phase.md) — run plans in parallel waves with fresh-context subagents
|
||||
|
||||
@@ -830,6 +830,18 @@ Set `commit_docs: false` during `/gsd-new-project` or via `/gsd-settings`. Add `
|
||||
|
||||
Since v1.17, the installer backs up locally modified files to `gsd-local-patches/`. Run `/gsd-update --reapply` to merge your changes back.
|
||||
|
||||
### Install or Refresh a Release Candidate
|
||||
|
||||
To install or refresh GSD from the `@next` RC dist-tag (the pre-release channel established by ADR #660), run:
|
||||
|
||||
```bash
|
||||
/gsd-update --next
|
||||
# or equivalently:
|
||||
/gsd-update --rc
|
||||
```
|
||||
|
||||
The same scope/runtime detection, changelog preview, custom-file backup, and cache clearing apply. Omitting `--next`/`--rc` keeps targeting `@latest` (stable channel, no change). Only the `@latest` and `@next` channels are supported — no arbitrary dist-tag can be passed.
|
||||
|
||||
### Cannot Update via npm
|
||||
|
||||
See [docs/manual-update.md](manual-update.md) for a step-by-step manual update procedure.
|
||||
|
||||
@@ -9,6 +9,7 @@ Maps the five canonical triage roles to the actual label strings in `open-gsd/gs
|
||||
| `ready-for-agent` | `confirmed` | Bug verified + fully specified — AFK agent can pick up |
|
||||
| `ready-for-human` | `approved-enhancement` / `approved-feature` | Enhancement/feature approved by maintainer — human codes it |
|
||||
| `wontfix` | `wontfix` | Will not be actioned |
|
||||
| `possible-duplicate` | `possible-duplicate` | Applied by the Duplicate check workflow when a new issue's title closely matches existing open issues. The reporter (or a maintainer) replies justifying why it is not a duplicate within 24h, or the Duplicate auto-close sweep closes it. A reply clears this label and applies needs-maintainer-review for human adjudication. React 👎 to the bot comment to veto auto-close. |
|
||||
|
||||
## Notes on this repo's label model
|
||||
|
||||
@@ -17,3 +18,12 @@ Maps the five canonical triage roles to the actual label strings in `open-gsd/gs
|
||||
- There is no separate "ready-for-human" vs "ready-for-agent" distinction for enhancements — both flow through the same `approved-*` labels. If the work requires human judgment (design decisions, external access), note it in the issue body.
|
||||
- `needs-triage` is removed when any other state label is applied.
|
||||
- `needs-reproduction` is used instead of the generic `needs-info` — be specific in triage comments about what reproduction steps or information are missing.
|
||||
|
||||
## Duplicate detection lifecycle
|
||||
|
||||
The `possible-duplicate` label is managed by three GitHub Actions workflows that together form a self-service deduplication loop:
|
||||
|
||||
1. **Detect on open** — When an issue is opened, `duplicate-check.yml` scores its title against all other open issues using Dice-coefficient similarity. If any match clears the threshold, the bot posts a challenge comment listing the similar issues and applies `possible-duplicate`.
|
||||
2. **Challenge comment + reporter window** — The reporter (or a maintainer) has `DEFAULT_WINDOW_HOURS` (24h) to reply explaining why the issue is not a duplicate. Reacting 👎 to the bot comment also signals the reporter objects to auto-close.
|
||||
3. **Daily sweep auto-close** — `duplicate-sweep.yml` runs at 07:00 UTC daily. For each open issue with `possible-duplicate`, it checks whether the window has elapsed, whether the reporter replied, and whether a 👎 reaction exists. Issues with exempt labels (`priority: critical`, `pinned`, `confirmed-bug`, `confirmed`, `fix-pending`) are never auto-closed. Issues that pass the close check receive a closing comment and are closed with `state_reason: duplicate`.
|
||||
4. **Reporter reply clears label** — `remove-duplicate-label.yml` fires on every new non-bot comment. If the issue still carries `possible-duplicate`, it removes that label and applies `needs-maintainer-review` (the value of `HUMAN_REVIEW_LABEL` in `scripts/issue-dedupe.cjs`), routing the issue to a maintainer for manual adjudication.
|
||||
|
||||
127
docs/how-to/install-minimal-and-add-skills.md
Normal file
127
docs/how-to/install-minimal-and-add-skills.md
Normal file
@@ -0,0 +1,127 @@
|
||||
# How to install a minimal GSD and add skills later
|
||||
|
||||
Install GSD Core with a small skill footprint to keep cold-start context low, then grow the surface — live or on reinstall — only when you need more. Use this when context budget matters: large existing projects, constrained models, or runtimes where every description token counts.
|
||||
|
||||
**What you need:** A supported runtime and the standard installer prerequisites (Node.js 18+ and npx). If you have not installed GSD at all yet, read [Install on your runtime](install-on-your-runtime.md) first — this guide covers the *profile* choice that layers on top of any runtime install.
|
||||
|
||||
---
|
||||
|
||||
## Install the minimal profile
|
||||
|
||||
To install only the core main-loop skills, add `--minimal` to the installer:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --claude --global --minimal
|
||||
```
|
||||
|
||||
`--minimal` has two aliases — use whichever reads best to you; they are identical:
|
||||
|
||||
```bash
|
||||
npx @opengsd/gsd-core@latest --claude --global --core-only
|
||||
npx @opengsd/gsd-core@latest --claude --global --profile=core
|
||||
```
|
||||
|
||||
A minimal install gives you the eight skills needed to run the core phase loop:
|
||||
|
||||
- `new-project`
|
||||
- `discuss-phase`
|
||||
- `plan-phase`
|
||||
- `execute-phase`
|
||||
- `phase`
|
||||
- `help`
|
||||
- `update`
|
||||
- `surface`
|
||||
|
||||
No sub-agents are installed, and the skill-description tokens the model carries at cold start drop to roughly 130, against roughly 1,200 for a full install. The chosen profile is recorded in the `.gsd-profile` marker in your runtime config directory and is reapplied automatically every time you run `/gsd-update`, so you stay minimal across upgrades until you decide otherwise.
|
||||
|
||||
> Do not combine `--minimal` with `--profile=` — the installer treats that as a conflict and exits.
|
||||
|
||||
---
|
||||
|
||||
## Choose a profile
|
||||
|
||||
If `core` is too small, pick a wider profile instead. Pass it with `--profile=<name>`:
|
||||
|
||||
| Profile | What you get | Approx. description tokens |
|
||||
|---------|--------------|--------------------------|
|
||||
| `core` | The eight core-loop skills above. No agents. | ~130 desc tokens |
|
||||
| `standard` | Everything in `core` plus common management skills — `review`, `config`, `progress`, `resume-work`, `pause-work`, `workspace` — and the sub-agents those skills need. | ~700 desc tokens |
|
||||
| `full` | Every skill and every sub-agent. This is the default when you pass no profile flag. | ~1,200 desc tokens |
|
||||
|
||||
```bash
|
||||
# Standard: the core loop plus everyday management commands
|
||||
npx @opengsd/gsd-core@latest --claude --global --profile=standard
|
||||
```
|
||||
|
||||
If you want a named profile plus one extra cluster, compose them with a comma. The installer writes the union of both:
|
||||
|
||||
```bash
|
||||
# Core loop plus the audit/review skills, nothing else
|
||||
npx @opengsd/gsd-core@latest --claude --global --profile=core,audit
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## See what is installed and what is available
|
||||
|
||||
From inside your runtime, list the current surface, the disabled clusters, and the token cost of each:
|
||||
|
||||
```bash
|
||||
/gsd:surface list
|
||||
```
|
||||
|
||||
The skills are grouped into clusters you can toggle as a unit:
|
||||
|
||||
`core_loop`, `audit_review`, `milestone`, `research_ideate`, `workspace_state`, `docs`, `ui`, `ai_eval`, `ns_meta`, `utility`
|
||||
|
||||
---
|
||||
|
||||
## Add skills later without reinstalling
|
||||
|
||||
If you installed minimal and now need more, you do not have to re-run the installer. `/gsd:surface` changes the live surface and persists the change in a separate `.gsd-surface.json` file, leaving your install-time profile marker untouched.
|
||||
|
||||
To switch to a wider profile in place:
|
||||
|
||||
```bash
|
||||
/gsd:surface profile standard
|
||||
```
|
||||
|
||||
To turn on just one cluster while keeping your base profile:
|
||||
|
||||
```bash
|
||||
/gsd:surface enable audit_review
|
||||
```
|
||||
|
||||
To turn a cluster back off, or to discard all your live changes and return to the profile you installed:
|
||||
|
||||
```bash
|
||||
/gsd:surface disable utility
|
||||
/gsd:surface reset
|
||||
```
|
||||
|
||||
Surface changes take effect in your next session — restart the runtime to pick them up.
|
||||
|
||||
---
|
||||
|
||||
## Add skills by reinstalling
|
||||
|
||||
`/gsd:surface` is the right tool for occasional, reversible adjustments. If you have decided you want the wider surface permanently, change the install-time profile instead so every future `/gsd-update` keeps it:
|
||||
|
||||
```bash
|
||||
# Re-run the installer without --minimal to record `full` as your profile
|
||||
npx @opengsd/gsd-core@latest --claude --global
|
||||
|
||||
# ...or pin a specific profile
|
||||
npx @opengsd/gsd-core@latest --claude --global --profile=standard
|
||||
```
|
||||
|
||||
Running `/gsd-update` re-reads the `.gsd-profile` marker and reinstalls at that profile, so a one-off reinstall at a new profile is all you need — subsequent updates follow it automatically.
|
||||
|
||||
---
|
||||
|
||||
## Related
|
||||
|
||||
- [Install on your runtime](install-on-your-runtime.md)
|
||||
- [Update GSD](update-gsd.md)
|
||||
- [Configuration](../CONFIGURATION.md)
|
||||
- [Docs index](../README.md)
|
||||
@@ -42,6 +42,22 @@ Skills land in `~/.claude/`. Commands appear as `/gsd-*` slash commands in your
|
||||
CLAUDE_CONFIG_DIR=~/.claude-alt npx @opengsd/gsd-core@latest --claude --global
|
||||
```
|
||||
|
||||
**Hook coverage**
|
||||
|
||||
GSD registers the following Claude Code hook events automatically on install:
|
||||
|
||||
| Event | Hook | Purpose |
|
||||
|---|---|---|
|
||||
| `SessionStart` | `gsd-check-update.js`, `gsd-session-state.sh` | Update check, session orientation |
|
||||
| `PostToolUse` | `gsd-context-monitor.js`, `gsd-read-injection-scanner.js`, `gsd-phase-boundary.sh`, `gsd-graphify-update.sh` | Context monitoring, read-time scan, phase boundary detection |
|
||||
| `PreToolUse` | `gsd-prompt-guard.js`, `gsd-read-guard.js`, `gsd-workflow-guard.js`, `gsd-worktree-path-guard.js`, `gsd-validate-commit.sh` | Prompt guard, read-before-edit, workflow + worktree safety, commit validation |
|
||||
| `SubagentStop` | `gsd-context-monitor.js` | Context headroom tracking after subagent completion |
|
||||
| `Stop` | `gsd-context-monitor.js` | Context headroom tracking before model stop |
|
||||
| `PreCompact` | `gsd-context-monitor.js` | Context awareness before conversation compaction |
|
||||
| `FileChanged` (matcher: `config.json`) | `gsd-config-reload.js` | Hot-reloads `.planning/config.json` context mid-session when you edit your GSD config — no session restart required |
|
||||
|
||||
The `FileChanged` hook is always-on and a no-op when `.planning/config.json` does not exist in the project. Editing that file while a session is running injects an `additionalContext` summary of the new configuration so the agent picks up model overrides, workflow toggles, and hook settings immediately.
|
||||
|
||||
---
|
||||
|
||||
### Claude Code — native plugin install
|
||||
@@ -107,6 +123,21 @@ The installer also enriches the generated TOML commands with two native Gemini c
|
||||
GEMINI_CONFIG_DIR=~/.gemini-alt npx @opengsd/gsd-core@latest --gemini --global
|
||||
```
|
||||
|
||||
**Hook coverage**
|
||||
|
||||
GSD registers the following hook events automatically on install:
|
||||
|
||||
| Event | Hook | Purpose |
|
||||
|---|---|---|
|
||||
| `SessionStart` | `gsd-check-update.js`, `gsd-session-state.sh` | Update check, session orientation |
|
||||
| `BeforeTool` | `gsd-prompt-guard.js`, `gsd-read-guard.js`, `gsd-workflow-guard.js`, `gsd-worktree-path-guard.js`, `gsd-validate-commit.sh` | Prompt guard, read-before-edit, workflow + worktree safety, commit validation |
|
||||
| `AfterTool` | `gsd-context-monitor.js`, `gsd-read-injection-scanner.js`, `gsd-phase-boundary.sh`, `gsd-graphify-update.sh` | Context monitoring, read-time scan, phase boundary detection |
|
||||
| `BeforeAgent` | `gsd-context-monitor.js` | Context headroom awareness before the agent begins planning each prompt |
|
||||
| `AfterAgent` | `gsd-context-monitor.js` | Context headroom tracking after each agent turn's final response |
|
||||
| `BeforeModel` | `gsd-context-monitor.js` | Per-turn context injection before each LLM call |
|
||||
|
||||
> **`hooksConfig.enabled: false` warning.** If your Gemini `settings.json` contains `hooksConfig.enabled: false`, the Gemini CLI silently disables all hook execution — GSD hooks are registered but will never run. The installer detects this and emits a warning. To enable hooks, set `hooksConfig.enabled: true` in `~/.gemini/settings.json` (or the directory matching your `GEMINI_CONFIG_DIR`).
|
||||
|
||||
---
|
||||
|
||||
### Gemini CLI — native extension install (#775)
|
||||
|
||||
@@ -35,14 +35,34 @@ Restart your runtime after the update to pick up new commands and agents.
|
||||
|------|--------------|
|
||||
| `--sync` | After updating, sync skills from the GSD registry |
|
||||
| `--reapply` | After updating, merge locally modified GSD files back in from `gsd-local-patches/` |
|
||||
| `--next` / `--rc` | Target the `@next` RC dist-tag instead of `@latest` (installs or refreshes a release candidate; see ADR #660) |
|
||||
|
||||
```bash
|
||||
/gsd-update --sync # Update and sync skills
|
||||
/gsd-update --reapply # Update and reapply local patches
|
||||
/gsd-update --next # Install from the @next RC dist-tag
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Install or refresh a release candidate
|
||||
|
||||
GSD publishes release candidates on the `@next` npm dist-tag (established by ADR #660). To install or refresh from that channel:
|
||||
|
||||
```bash
|
||||
/gsd-update --next
|
||||
# or equivalently:
|
||||
/gsd-update --rc
|
||||
```
|
||||
|
||||
The full update flow applies — scope/runtime detection, changelog preview, custom-file backup, and cache clearing all run normally. The only difference is that `check-latest-version.cjs` resolves the `@next` tag and npx installs from `@opengsd/gsd-core@next`.
|
||||
|
||||
Only `latest` and `next` are supported channels; no arbitrary dist-tag can be passed (the script enforces an allowlist and exits with code 2 on an invalid tag).
|
||||
|
||||
Omitting `--next`/`--rc` keeps targeting `@latest` (stable channel, no change in behavior).
|
||||
|
||||
---
|
||||
|
||||
## Reviewing the changelog before updating
|
||||
|
||||
`/gsd-update` always shows the changelog diff between your installed version and the latest *before* it asks for confirmation. You do not need to visit GitHub separately. The output looks like:
|
||||
|
||||
@@ -372,7 +372,7 @@ for the new shape before changing migration behavior.
|
||||
| Codex | Skills in `skills/gsd-*/SKILL.md`; agents as source markdown plus per-agent TOML in `agents/`; `[agents.gsd-*]` and hooks in `config.toml` | Global `CODEX_HOME` or `~/.codex`; local `./.codex` | GSD owns generated skills, generated agent TOML, `agents.gsd-*` config sections, `[features].hooks` when added by GSD (canonical; legacy alias `codex_hooks` is recognized and migrated forward, #3566), and GSD hook entries | [Codex config schema](https://developers.openai.com/codex/config-schema.json), [Codex developer docs](https://developers.openai.com/codex/); docs not versioned, checked 2026-05-15; installer compatibility sentinel: Codex 0.130.0 features.hooks key (legacy `codex_hooks` recognized) |
|
||||
| GitHub Copilot | Skills in `skills/gsd-*/SKILL.md`; agents as `.agent.md`; repository instructions in `copilot-instructions.md` | Global `COPILOT_CONFIG_DIR`, `COPILOT_HOME`, or `~/.copilot`; local `./.github` | GSD owns generated skill/agent files and GSD-authored instruction files; no hook/statusline ownership | [Repository custom instructions](https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions), [Copilot CLI custom instructions](https://docs.github.com/en/copilot/how-tos/copilot-cli/add-custom-instructions); GitHub Docs product docs, checked 2026-05-11 |
|
||||
| Antigravity | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/`; Gemini-style `settings.json` hooks when installed by GSD | Global `ANTIGRAVITY_CONFIG_DIR` or `~/.gemini/antigravity`; local `./.agent` | GSD owns generated skills/agents/hooks and GSD settings entries only | Public Antigravity install/config docs for this file layout were not stable or complete as of 2026-05-11; installer compatibility therefore uses GSD's Gemini-compatible settings policy, documented shim baseline. |
|
||||
| Cursor | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/`; rule references under `rules/` | Global `CURSOR_CONFIG_DIR` or `~/.cursor`; local `./.cursor` | GSD owns generated skills/agents and GSD rule files or references; no hook/statusline ownership | [Cursor rules](https://docs.cursor.com/context/rules); docs not versioned, checked 2026-05-11 |
|
||||
| Cursor | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/`; rule references under `rules/`; lifecycle hooks via `hooks.json` (sessionStart + postToolUse, #777) | Global `CURSOR_CONFIG_DIR` or `~/.cursor`; local `./.cursor` | GSD owns generated skills/agents, GSD rule files or references, and GSD-managed `hooks.json` entries (sentinel `gsd-managed:true`); no statusline ownership | [Cursor rules](https://docs.cursor.com/context/rules); [Cursor hooks](https://docs.cursor.com/context/hooks); docs not versioned, checked 2026-06-07 |
|
||||
| Windsurf | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/`; rule references under `rules/` | Global `WINDSURF_CONFIG_DIR` or `~/.codeium/windsurf`; local `./.windsurf` | GSD owns generated skills/agents and GSD rule files or references; no hook/statusline ownership | Windsurf public rule docs were source-limited in search results as of 2026-05-11; installer targets the common workspace rules convention `./.windsurf/rules` and must be rechecked before migrations rewrite rules |
|
||||
| Augment Code | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/` | Global `AUGMENT_CONFIG_DIR` or `~/.augment`; local `./.augment` | GSD owns generated skills/agents only; no hook/statusline ownership | [Augment Agent Skills](https://docs.augmentcode.com/cli/skills), [Augment IDE skills](https://docs.augmentcode.com/using-augment/skills); IDE skills public beta in VS Code 0.789.0+, checked 2026-05-11 |
|
||||
| Trae | Skills in `skills/gsd-*/SKILL.md`; agents in `agents/`; rule references under `rules/` | Global `TRAE_CONFIG_DIR` or `~/.trae`; local `./.trae` | GSD owns generated skills/agents and GSD rule files or references; no hook/statusline ownership | Public Trae docs expose AI settings and `.rules` announcements, but no stable skills/config API was found as of 2026-05-11; migrations must treat this row as source-limited |
|
||||
|
||||
Reference in New Issue
Block a user