Add initial OpenClaw compatibility subtree

openclaw/README.md

@@ -0,0 +1,27 @@
+# OpenClaw compatibility
+
+This subtree contains OpenClaw-native adaptations of selected gstack workflows. It is meant to be understandable and usable by OpenClaw agents without requiring Claude-specific hooks or generated preambles.
+
+Goals:
+- preserve the role/workflow value of gstack
+- avoid Claude-specific tools and hooks
+- map browser and orchestration guidance to OpenClaw primitives
+
+Non-goals:
+- full Claude Code runtime parity
+- automatic conversion of every generated skill/template
+- preserving gstack telemetry or repo-mode shell wrappers
+
+Suggested mapping:
+- Claude/Codex browser helpers -> OpenClaw `browser`
+- sub-agent review flows -> OpenClaw `sessions_spawn` / `subagents`
+- 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.
+
+
+See `openclaw/references/skill-index.md` for a quick index of the ported skills.

openclaw/openclaw-port-notes.md

@@ -0,0 +1,16 @@
+# OpenClaw port notes
+
+This is an initial compatibility layer, not full parity.
+
+What was ported:
+- product idea diagnostic (`gstack-office-hours`)
+- CEO review (`gstack-plan-ceo-review`)
+- engineering review (`gstack-plan-eng-review`)
+- structured review (`gstack-review`)
+- investigation workflow (`gstack-investigate`)
+
+What remains future work:
+- QA/browser-heavy skills tuned to OpenClaw browser snapshots/actions
+- ship/deploy flows mapped to OpenClaw ACP sessions and GitHub flows
+- safety skills adapted to OpenClaw approval semantics
+- generator support to emit OpenClaw variants automatically

openclaw/references/gstack-port-notes.md

@@ -0,0 +1,41 @@
+# 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.
+
+
+## Gaps and follow-ups
+
+- The safety-mode ports are advisory rather than hook-enforced.
+- Browser-heavy skills depend on OpenClaw browser availability and sometimes user presence for auth.
+- The compatibility subtree does not yet integrate with gstack's template generator, so OpenClaw variants are maintained separately for now.
+- The quality of these ports comes from concise workflow transfer, not 1:1 feature parity.

openclaw/references/skill-index.md

@@ -0,0 +1,41 @@
+# OpenClaw ported skill index
+
+## Product / planning
+- `gstack-office-hours` — YC-style startup and product diagnostic
+- `gstack-plan-ceo-review` — product/narrative review
+- `gstack-plan-eng-review` — engineering plan review
+
+## Review / debugging / security
+- `gstack-review` — pre-ship review
+- `gstack-investigate` — root-cause debugging
+- `gstack-cso` — security review
+- `gstack-codex` — independent coding-agent second opinion
+
+## QA / design
+- `gstack-qa` — test, fix, re-verify
+- `gstack-qa-only` — report-only QA
+- `gstack-design-review` — visual/interaction audit
+- `gstack-design-consultation` — design direction and system planning
+- `gstack-setup-browser-cookies` — authenticated browser setup guidance
+
+## Shipping / deploy / docs
+- `gstack-ship` — pre-merge branch hardening
+- `gstack-land-and-deploy` — merge + deploy + verify
+- `gstack-canary` — immediate post-deploy smoke verification
+- `gstack-setup-deploy` — discover and document deploy context
+- `gstack-document-release` — update docs after shipping
+
+## Safety / scope control
+- `gstack-careful` — caution before destructive actions
+- `gstack-freeze` — restrict edits to a declared area
+- `gstack-guard` — combine careful + freeze
+- `gstack-unfreeze` — remove or widen the declared boundary
+
+## Reflection
+- `gstack-retro` — retrospective over a sprint/release/work window
+
+## What remains intentionally incomplete
+These ports preserve role and workflow value, not full runtime parity with Claude Code. In particular:
+- no Claude hook enforcement for safety modes
+- no generated-skill pipeline for OpenClaw variants yet
+- no automatic cookie import or gstack browse daemon parity

openclaw/references/tool-mapping.md

@@ -0,0 +1,16 @@
+# gstack -> OpenClaw tool mapping
+
+- `Read` -> `read`
+- `Write` -> `write`
+- `Edit` -> `edit`
+- `Bash` -> `exec`
+- `WebSearch` -> `web_search`
+- browser helpers / `$B ...` -> `browser`
+- `AskUserQuestion` -> ask directly in the chat reply
+- agent handoffs -> `sessions_spawn` or `subagents`
+
+Porting rules:
+1. Remove Claude-specific preambles, hooks, telemetry, and shell wrappers.
+2. Keep the role, diagnostic posture, and workflow sequence.
+3. Prefer first-class OpenClaw tools over custom scripts.
+4. When a skill depends on multi-agent review, instruct the agent to spawn subagents only when the task is materially complex.

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-investigate/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: gstack-investigate
+description: Root-cause investigation workflow for OpenClaw. Use when debugging incidents, confusing failures, flaky behavior, mismatched outputs, or unclear technical problems before attempting a fix.
+---
+
+Do not jump to fixes before understanding the failure.
+
+Workflow:
+1. State the symptom clearly.
+2. Reproduce or inspect evidence.
+3. Form 2-3 plausible hypotheses.
+4. Test the hypotheses with the smallest useful checks.
+5. Identify the root cause or narrow the uncertainty.
+6. Only then propose the fix.

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-office-hours/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: gstack-office-hours
+description: YC-style product and startup diagnostic for OpenClaw. Use when evaluating a new product idea, founder pitch, wedge, GTM, startup narrative, or whether something is worth building before implementation.
+---
+
+Use this skill to pressure-test ideas before code or product build-out.
+
+Principles:
+- Force specificity.
+- Distinguish interest from demand.
+- Treat the status quo as the real competitor.
+- Prefer a narrow wedge over a broad platform claim.
+- End with one concrete next action.
+
+Workflow:
+1. Summarize the idea and context in plain language.
+2. Ask what the user's goal is with the idea.
+3. For startups/intrapreneurship, use a YC-style diagnostic:
+   - strongest evidence of demand
+   - current workaround / status quo
+   - most desperate user
+   - narrowest wedge someone would pay for now
+   - direct observation or surprise from user behavior
+   - why the product becomes more essential over time
+4. Push past vague answers. Ask follow-ups until specifics appear.
+5. Produce a short memo or design note, not implementation.
+
+Do not implement code when using this skill unless the user explicitly changes scope.