Merge 0d72cd4140 into 2beb636f7c

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.

openclaw/skills/gstack-plan-ceo-review/SKILL.md

@@ -0,0 +1,20 @@
+---
+name: gstack-plan-ceo-review
+description: CEO-style product review for OpenClaw. Use when reviewing a product plan, roadmap, pitch, wedge, positioning, user value, or product strategy to find the strongest version of the idea.
+---
+
+Review the plan like a demanding CEO.
+
+Focus on:
+- what users truly care about
+- the sharpest wedge
+- why this wins versus doing nothing
+- whether the narrative is memorable
+- whether the plan earns expansion into a larger platform
+
+Output:
+- what is strong
+- what is weak or blurry
+- what to cut
+- what to emphasize
+- one recommended next version of the narrative or plan

openclaw/skills/gstack-plan-eng-review/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: gstack-plan-eng-review
+description: Engineering plan review for OpenClaw. Use when evaluating architecture, implementation plans, sequencing, dependencies, testing, data flow, failure modes, or technical scope before coding.
+---
+
+Review for execution realism.
+
+Check:
+- architecture and sequencing
+- hidden dependencies
+- edge cases and failure modes
+- testing strategy
+- observability and rollback
+- whether the plan is too broad for the current stage
+
+Output a concise engineering assessment with recommended sequencing.

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

@@ -0,0 +1,15 @@
+---
+name: gstack-review
+description: Structured pre-ship review for OpenClaw. Use when reviewing code, plans, docs, or changes for bugs, regressions, poor assumptions, missing tests, or production risks before shipping.
+---
+
+Review with skepticism.
+
+Look for:
+- breakage that happy-path checks miss
+- missing tests
+- unsafe assumptions
+- UX or product regressions
+- operational risks
+
+If the change is large, consider recommending a subagent review pass.

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

openclaw/skills/gstack-unfreeze/SKILL.md

@@ -0,0 +1,14 @@
+---
+name: gstack-unfreeze
+description: Remove or relax an explicit edit-boundary in OpenClaw. Use when a prior gstack-freeze or gstack-guard constraint is no longer appropriate and the allowed scope needs to expand in a controlled way.
+---
+
+Use this as the companion to `gstack-freeze`.
+
+Workflow:
+1. Restate the current boundary.
+2. Confirm whether the boundary is being removed entirely or expanded to a larger path.
+3. If only expanding, define the new boundary clearly.
+4. Continue with the updated scope and avoid silent drift beyond it.
+
+Because this OpenClaw port is procedural rather than hook-enforced, the main value is making scope changes explicit and visible.