Add OpenClaw ports for major gstack skills

openclaw/README.md

@@ -18,3 +18,7 @@ Suggested mapping:
 - file operations -> OpenClaw `read`, `write`, `edit`
 - shell commands -> OpenClaw `exec`
 - user follow-ups -> normal chat replies or `message`
+
+Ported skill set currently includes review, investigation, office-hours/product planning, QA, design review/consultation, ship + deploy flows, post-ship docs, canary checks, safety modes, security review, retrospective, authenticated browser setup, and delegated coding-agent consultation.
+
+See `openclaw/references/gstack-port-notes.md` for the main runtime translation choices and limitations.

openclaw/references/gstack-port-notes.md

@@ -0,0 +1,33 @@
+# gstack → OpenClaw port notes
+
+This compatibility subtree keeps the spirit of selected gstack skills while adapting them to OpenClaw's actual runtime.
+
+## Translation principles
+
+- Prefer OpenClaw-native tools over Claude-specific wrappers and hooks.
+- Keep skills concise and operational rather than reproducing long generated preambles.
+- Be explicit when a gstack behavior cannot be enforced automatically in OpenClaw.
+- Point to an existing first-party OpenClaw skill when it is a better fit than a literal port.
+
+## Notable adaptations
+
+### Browser and auth flows
+
+- gstack browse-daemon flows map to OpenClaw `browser` actions.
+- Authenticated testing is usually done by attaching to the user's real browser (`profile="user"`) or Browser Relay (`profile="chrome-relay"`) when explicitly requested.
+- Automatic cookie import is not assumed.
+
+### Safety modes
+
+- Original gstack `careful`, `freeze`, and `guard` use Claude hook enforcement.
+- OpenClaw ports keep the same intent, but rely on explicit operator discipline because those hook semantics are not available in this subtree.
+
+### Deploy / merge flows
+
+- PR and CI operations should prefer the OpenClaw `github` skill when `gh` is available.
+- Runtime deploy commands stay repo-specific and should be discovered from project docs or config rather than hard-coded in the skill.
+
+### Independent agent review
+
+- gstack's `codex` idea maps best to delegating with the `coding-agent` skill in OpenClaw.
+- Use a read-only independent pass by default unless the user explicitly asks for fixes.

openclaw/skills/gstack-canary/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: gstack-canary
+description: Post-deploy canary check for OpenClaw. Use when monitoring a fresh deploy for obvious regressions, console errors, broken flows, or health-check failures in the first validation window.
+---
+
+Canary work is short, skeptical production verification.
+
+Workflow:
+1. Identify the production or staging URL and the most important flows.
+2. Check health endpoints or status pages if they exist.
+3. Load the app with `browser`, watch for console errors, and exercise key paths.
+4. Compare behavior to the expected baseline.
+5. Report anomalies quickly and clearly.
+
+This skill is for verification, not long-running synthetic monitoring.
+If sustained monitoring is needed, recommend dedicated observability tooling.

openclaw/skills/gstack-careful/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: gstack-careful
+description: Safety-first operating mode for OpenClaw. Use when working near production, shared infra, or risky git/database changes and you want extra caution before destructive actions.
+---
+
+OpenClaw does not support Claude-style tool hooks here, so apply the behavior manually.
+
+Behavior:
+- slow down before destructive commands
+- explain risk before force-push, hard reset, delete, migration, or prod actions
+- prefer reversible steps and recoverable paths
+- ask before anything that could lose data or disrupt live systems
+
+Checklist before risky actions:
+1. Name the command or action.
+2. State what could break or be lost.
+3. Confirm backups, rollback path, or safer alternative.
+4. Ask the user if impact is meaningful or irreversible.
+
+This skill is mostly procedural discipline, not automation.

openclaw/skills/gstack-codex/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: gstack-codex
+description: External coding-agent second opinion for OpenClaw. Use when you want an independent review, adversarial critique, or consultation from Codex or another delegated coding agent.
+---
+
+In OpenClaw, prefer the `coding-agent` skill rather than assuming a local Codex wrapper.
+
+Modes:
+- review: ask a coding agent to inspect a diff or implementation and report issues
+- challenge: ask it to actively try to break assumptions or find edge cases
+- consult: ask focused technical questions and summarize the advice
+
+Workflow:
+1. Define the question or review scope precisely.
+2. Delegate with `coding-agent` if the task merits an independent pass.
+3. Keep the request read-only unless fixes are explicitly desired.
+4. Summarize findings with your own judgment instead of blindly deferring.

openclaw/skills/gstack-cso/SKILL.md

@@ -0,0 +1,23 @@
+---
+name: gstack-cso
+description: Security review mode for OpenClaw. Use when auditing an application, repo, CI pipeline, or deployment setup for secrets exposure, dependency risk, auth weaknesses, unsafe defaults, and operational security gaps.
+---
+
+Think like a pragmatic security lead, not a checklist robot.
+
+Areas to inspect:
+- leaked secrets or unsafe secret handling
+- authn/authz gaps and exposed admin paths
+- dependency and supply-chain risk
+- CI/CD permissions and deployment trust boundaries
+- prompt injection, model abuse, or AI-specific attack surface if relevant
+- logging, observability, and incident-response blind spots
+
+Workflow:
+1. Define scope: app, infra, repo, or all three.
+2. Gather evidence from code, config, docs, and CI files.
+3. Prioritize findings by exploitability and impact.
+4. Recommend the smallest meaningful remediations first.
+5. Separate confirmed issues from plausible concerns.
+
+If the task expands into host hardening for an OpenClaw machine, prefer the `healthcheck` skill.

openclaw/skills/gstack-design-consultation/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: gstack-design-consultation
+description: Up-front design-system and product-design consultation for OpenClaw. Use when shaping a new interface, design language, or DESIGN.md before implementation starts.
+---
+
+This is planning, not polishing existing code.
+
+Workflow:
+1. Understand the product, user, and context.
+2. Research comparable products or interaction patterns when useful.
+3. Propose a coherent design direction: tone, typography, color, layout, spacing, and motion.
+4. Turn that direction into a reusable system or design brief.
+5. Leave the project with a clear source of truth, usually a `DESIGN.md` or equivalent note.
+
+Prefer:
+- `read` for current docs and product context
+- `web_search` / `web_fetch` for landscape research
+- `write` for the resulting design brief
+
+Output should be opinionated and actionable, not vague inspiration.

openclaw/skills/gstack-design-review/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: gstack-design-review
+description: Visual and interaction review for OpenClaw. Use when auditing an implemented UI for hierarchy, spacing, clarity, consistency, polish, and obvious UX rough edges before shipping.
+---
+
+Review the product with a designer's skepticism.
+
+Look for:
+- weak hierarchy or unclear emphasis
+- spacing and alignment inconsistencies
+- awkward states, empty states, and loading behavior
+- visually noisy or generic AI-looking UI
+- slow, confusing, or surprising interactions
+
+Workflow:
+1. Inspect the main screens and critical flows.
+2. Capture specific issues with screenshots or references.
+3. Prioritize the changes that most improve clarity and trust.
+4. Apply polish fixes directly when practical.
+5. Re-check before/after behavior.
+
+Use `browser` heavily for inspection and screenshots. Use `edit` / `write` / `exec` only after the design problem is concrete.

openclaw/skills/gstack-document-release/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: gstack-document-release
+description: Post-ship documentation sync for OpenClaw. Use after meaningful changes land to update README, architecture notes, changelog entries, release docs, or operational instructions so docs match reality.
+---
+
+Documentation debt compounds fast after shipping.
+
+Workflow:
+1. Read the shipped diff or summarize what changed.
+2. Identify the docs most affected.
+3. Update user-facing, contributor-facing, and operational docs as needed.
+4. Remove stale claims, TODOs, and outdated instructions.
+5. Summarize what documentation now reflects.
+
+Prefer concise, accurate edits over broad rewrites.
+If the project has explicit release notes, keep tone and format consistent with existing entries.

openclaw/skills/gstack-freeze/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: gstack-freeze
+description: Edit-scope discipline for OpenClaw. Use when you want changes limited to one directory, package, or file area so unrelated parts of the repo stay untouched.
+---
+
+OpenClaw does not provide the original gstack hook-based enforcement here.
+Use this skill as an explicit boundary-setting rule.
+
+Workflow:
+1. State the allowed edit boundary in the reply.
+2. Before each edit, check whether the target path is inside that boundary.
+3. Refuse or ask before changing files outside the frozen area.
+4. Re-state the boundary if the task starts to drift.
+
+Good uses:
+- debugging one module without opportunistic cleanup
+- minimizing blast radius in a large repo
+- protecting unrelated code during focused refactors

openclaw/skills/gstack-guard/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: gstack-guard
+description: Combined safety mode for OpenClaw. Use when you want both destructive-action caution and a strict edit boundary while working in a sensitive repo area.
+---
+
+This is the combination of `gstack-careful` and `gstack-freeze` behaviors.
+
+Behavior:
+- define a concrete edit boundary first
+- avoid edits outside that boundary unless the user expands scope
+- pause before destructive commands or live-environment actions
+- prefer reversible steps, dry runs, and explicit confirmations
+
+Suggested opening move:
+1. Ask or confirm the allowed path.
+2. State that all edits will stay inside it.
+3. State that risky commands will be called out before execution.
+
+Use this when the cost of accidental drift or damage is high.

openclaw/skills/gstack-land-and-deploy/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: gstack-land-and-deploy
+description: Merge-and-verify workflow for OpenClaw. Use after a branch is ready to land and the goal is to merge, watch CI or deploy progress, and confirm production health.
+---
+
+Treat deployment as incomplete until production looks healthy.
+
+Workflow:
+1. Confirm what branch or PR is being landed and where it deploys.
+2. Merge using the repo's normal path.
+3. Monitor CI and deployment status.
+4. Verify the production URL, health checks, and a few critical user journeys.
+5. Escalate or roll back only with explicit user direction if things are broken.
+
+Prefer:
+- `github` skill for PR status, merge actions, and CI logs
+- `browser` for smoke-testing production
+- `exec` for deploy tooling already used by the repo
+
+End with a clear status: landed, deployed, verified, or blocked.

openclaw/skills/gstack-qa-only/SKILL.md

@@ -0,0 +1,25 @@
+---
+name: gstack-qa-only
+description: Report-only QA for OpenClaw. Use when the user wants a structured bug report, reproduction evidence, and release risk assessment without making code changes.
+---
+
+Do not edit code in this mode.
+
+Workflow:
+1. Confirm target environment and core journeys to test.
+2. Exercise the most important flows first.
+3. Capture screenshots, console errors, and exact repro steps.
+4. Classify issues by severity and likelihood.
+5. Summarize product risk and recommended next fixes.
+
+Prefer:
+- `browser` for live testing and evidence capture
+- `exec` for running existing test suites if useful
+- `read` for understanding expected behavior
+
+Deliver a concise QA report with:
+- scope tested
+- bugs found
+- severity per bug
+- evidence / repro steps
+- release recommendation

openclaw/skills/gstack-qa/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: gstack-qa
+description: Full QA pass for an app or feature in OpenClaw. Use when testing a site, flow, or release candidate end-to-end, documenting bugs, and fixing or delegating high-confidence issues before re-testing.
+---
+
+Treat QA as a test-fix-verify loop.
+
+Workflow:
+1. Clarify scope, environment, and risk areas.
+2. Reproduce the app locally or identify the target URL.
+3. Test critical user journeys first, then secondary flows.
+4. Record concrete bugs with repro steps, severity, and evidence.
+5. Fix straightforward issues directly or delegate larger implementation work.
+6. Re-test the affected paths and summarize remaining risk.
+
+Use OpenClaw tools naturally:
+- `browser` for interactive testing, console logs, screenshots, and authenticated flows
+- `exec` for running the app, tests, linters, and builds
+- `read` / `edit` / `write` for targeted fixes
+- `coding-agent` skill if bug fixing becomes broad or iterative
+
+Output should include:
+- tested scope
+- issues found, grouped by severity
+- fixes applied
+- what was re-verified
+- ship recommendation: ready / risky / blocked

openclaw/skills/gstack-retro/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: gstack-retro
+description: Engineering retrospective for OpenClaw. Use when summarizing what shipped, what changed, where the team struggled, and what to improve after a sprint, release, or work week.
+---
+
+A useful retro creates insight and one or two concrete improvements.
+
+Workflow:
+1. Gather the time window, branch history, PRs, or shipped changes.
+2. Summarize output: features, fixes, incidents, and churn.
+3. Identify patterns: repeated bugs, review bottlenecks, unclear ownership, or flaky tooling.
+4. Call out wins worth repeating.
+5. End with a short list of process changes or follow-ups.
+
+Good evidence sources:
+- `git log`, `git shortlog`, and PR history via `exec` or `github`
+- release notes, issue trackers, and incident notes
+
+Avoid turning the retro into blame assignment.

openclaw/skills/gstack-setup-browser-cookies/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: gstack-setup-browser-cookies
+description: Authenticated-browser setup for OpenClaw. Use when QA or live testing requires existing user cookies or a manual login in a real browser session.
+---
+
+Do not promise automatic cookie import if the environment does not support it.
+
+Preferred OpenClaw-native approach:
+1. Ask whether the user is present to help with browser attachment or login.
+2. Use `browser` with `profile="user"` when existing local browser cookies matter.
+3. If the user specifically mentions the Browser Relay extension or attach-tab flow, use `profile="chrome-relay"`.
+4. Let the user complete any manual auth steps, then continue testing in the attached browser context.
+
+If browser attachment is unavailable, fall back to asking the user to log in within the controlled browser session and continue from there.

openclaw/skills/gstack-setup-deploy/SKILL.md

@@ -0,0 +1,15 @@
+---
+name: gstack-setup-deploy
+description: Deployment-setup helper for OpenClaw. Use when figuring out how a repo deploys, documenting the deploy path, and capturing enough operational context for future land-and-deploy runs.
+---
+
+The goal is reusable deploy context, not magic.
+
+Workflow:
+1. Detect likely deploy platform from repo files, CI config, and docs.
+2. Find production URLs, health checks, and relevant commands.
+3. Record how to deploy, verify, and troubleshoot in repo docs.
+4. Note any secrets, manual approval steps, or browser-based gaps that still require a human.
+
+Prefer writing to the compatibility subtree or existing operational docs rather than inventing hidden state.
+A good result is a concise deploy note another agent could follow without guesswork.

openclaw/skills/gstack-ship/SKILL.md

@@ -0,0 +1,19 @@
+---
+name: gstack-ship
+description: Pre-merge shipping workflow for OpenClaw. Use when preparing a branch to land: verify diff quality, run checks, update release notes if needed, commit cleanly, and prepare a PR or merge request.
+---
+
+Ship means making the branch ready to land, not blindly pushing code.
+
+Workflow:
+1. Inspect branch status and diff against the target base.
+2. Run the smallest credible validation: tests, lint, build, or smoke checks.
+3. Review the diff for accidental churn, debug code, or missing docs.
+4. Update changelog, version, or release notes only if the repo uses them.
+5. Create clean commits and prepare the PR summary.
+6. Hand off to `gstack-land-and-deploy` if the task continues through merge and production verification.
+
+Use:
+- `exec` for git, tests, and release checks
+- `read` for repo docs and release conventions
+- `github` skill if PR creation or CI inspection is needed