Update to gstack Workflows

{
  "description": "Route software product, planning, review, QA, debugging, design, security, release, documentation, browser, iOS, and safety requests to the right gstack workflow.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 218
    }
  ],
  "name": "gstack",
  "skill_md_contents": "---\nname: gstack\ndescription: Route software product, planning, review, QA, debugging, design, security, release, documentation, browser, iOS, and safety requests to the right gstack workflow.\n---\n\n# gstack Router\n\nRoute a request to the smallest matching gstack Skill. If the user names a Skill directly, use it. For a complex delivery request, chain only the phases needed and keep planning, mutation, verification, and release gates distinct.\n\n## Routing rules\n\n1. Start with intent, not keywords.\n2. Prefer one specialist Skill for a bounded request.\n3. For a build request with material ambiguity or cross-module impact, use `spec` or the relevant plan review before implementation.\n4. For defects, use `investigate` before fixing when root cause is unclear.\n5. Use `review` before landing material changes.\n6. Use `qa-only` when the user wants findings without edits, and `qa` when fixes are explicitly in scope.\n7. Use safety Skills as constraints around another workflow, not as substitutes for it.\n8. Native browser, pairing, gbrain, and iOS workflows require compatible local capabilities. Never simulate them.\n\n## Available workflows\n\n- `office-hours`: Reframe a product idea before implementation begins.\n- `plan-ceo-review`: Challenge a plan from product and company-value angles before implementation.\n- `plan-eng-review`: Review architecture, data flow, failure modes, edge cases, and test strategy before coding.\n- `plan-design-review`: Review product and interface design dimensions before implementation.\n- `plan-devex-review`: Review developer experience, time to first success, friction, and persona paths.\n- `plan-tune`: Tune when the workflow should ask questions versus proceed with safe assumptions.\n- `autoplan`: Run coordinated product, design, engineering, and developer-experience plan reviews.\n- `design-consultation`: Create or refine a design system and its implementation guidance.\n- `spec`: Turn vague intent into a precise executable specification with acceptance criteria.\n- `review`: Review a change before landing and find defects that can pass CI but fail in production.\n- `codex`: Provide a second-opinion code or plan review using available Codex reasoning and workspace evidence.\n- `investigate`: Run systematic root-cause investigation before proposing a fix.\n- `design-review`: Audit an implemented interface against design quality, usability, and consistency criteria.\n- `design-shotgun`: Generate and compare several materially different design directions before selecting one.\n- `design-html`: Create production-oriented HTML and CSS from an approved design direction.\n- `devex-review`: Audit a real developer workflow and measure friction against the actual path.\n- `qa`: Run end-to-end QA, fix authorized defects, and re-verify them when host tools permit.\n- `qa-only`: Run end-to-end QA and report findings without changing code.\n- `scrape`: Extract structured data from a web page using the safest available browser or web capability.\n- `skillify`: Convert a proven repeatable workflow into a reusable Skill with clear triggers and checks.\n- `ship`: Prepare a change for delivery by checking tests, review evidence, repository state, and release steps.\n- `land-and-deploy`: Land an approved change, observe CI and deployment, and verify production health when host access permits.\n- `canary`: Run post-deploy checks and surface regressions after a release.\n- `landing-report`: Summarize delivery status and release queue state without modifying anything.\n- `document-release`: Update release-facing documentation to match shipped behavior.\n- `document-generate`: Generate practical documentation from code and verified behavior.\n- `setup-deploy`: Inspect a repository and establish deployment configuration guidance without inventing provider details.\n- `gstack-upgrade`: Check and update an installed native gstack runtime only when the host can execute local commands and the user authorizes it.\n- `context-save`: Save concise project context, decisions, git state, and remaining work into the workspace when writing is available.\n- `context-restore`: Restore saved project context and verify it against the current repository state.\n- `learn`: Capture, inspect, and maintain project learnings backed by observed evidence.\n- `retro`: Produce a retrospective from repository evidence, delivery outcomes, and recorded learnings.\n- `health`: Assess codebase health using available type checks, linting, tests, dead-code signals, and repository evidence.\n- `benchmark`: Measure performance and compare against a known baseline using available execution or browser tools.\n- `benchmark-models`: Compare model performance on the same bounded workflow with explicit scoring criteria.\n- `cso`: Perform an evidence-backed security review using OWASP and STRIDE-oriented checks.\n- `setup-gbrain`: Configure gbrain integration only when the native local runtime and required credentials are available.\n- `sync-gbrain`: Refresh gbrain project context only when the native local runtime is available and the user authorizes the sync.\n- `browse`: Drive the native gstack browser when available; otherwise use host browser capabilities without pretending gstack is running.\n- `open-gstack-browser`: Open the native visible gstack browser only on a compatible local host.\n- `setup-browser-cookies`: Import browser cookies into native gstack only with explicit user authorization on a compatible local host.\n- `pair-agent`: Pair an authorized agent with native gstack browser access while preserving scope and revocation controls.\n- `ios-qa`: Run QA on a real iOS device only when a compatible local device bridge is available.\n- `ios-fix`: Investigate and fix iOS defects with regression checks on a compatible local device workflow.\n- `ios-design-review`: Review an iOS interface against Apple platform conventions using real device evidence when available.\n- `ios-clean`: Remove development-only iOS bridge wiring before release after verifying the target scope.\n- `ios-sync`: Regenerate native iOS debug bridge artifacts only on a compatible local host.\n- `careful`: Apply an extra safety check before destructive or difficult-to-reverse operations.\n- `freeze`: Restrict requested edits to an explicitly named directory or scope.\n- `guard`: Combine destructive-operation checks with a strict edit scope.\n- `unfreeze`: Remove a previously established edit-scope restriction when the user explicitly requests it.\n- `make-pdf`: Turn markdown or structured content into a PDF using the host document or Python capabilities when available.\n- `diagram`: Create a technical diagram from a textual description and return editable source when the host supports artifacts.\n\n## Host portability\n\nThe original gstack project contains local runtime features. This plugin keeps its public workflow names and intent but maps operations to ChatGPT/Codex host capabilities. When a compatible original gstack install exists on Codex, specialist Skills may defer to the current installed upstream workflow for native execution.\n"
}