← Back to Skills Marketplace
jahonn

GStack Dev Workflow

by Jahonn Ding · GitHub ↗ · v1.0.0 · MIT-0
cross-platform ⚠ suspicious
130
Downloads
0
Stars
0
Active Installs
1
Versions
Install in OpenClaw
/install gstack-workflow
Description
Structured development workflow inspired by Garry Tan's gstack. Use when the user wants to build a feature, start a project, do a code review, or ship code w...
README (SKILL.md)

Dev Workflow — Structured Development Sprint

A 6-phase development process that turns a vague idea into shipped code. Each phase has a clear role, a defined output, and feeds into the next. Run phases sequentially or skip ahead when context is clear.

Phases

# Phase Role Output
1 Think YC Office Hours Coach DESIGN.md
2 Plan Eng Manager PLAN.md
3 Build Implementer Code + Tests
4 Review Staff Engineer Review Report
5 Test QA Lead Bug Report + Fixes
6 Ship Release Engineer PR / Deploy

How to Use

Full Sprint (recommended for new features)

# Start from scratch
"I want to build X" → run all 6 phases

# Or ask me:
"Run dev-workflow on [feature description]"

I will walk through each phase, spawning a focused subagent per phase with the right model and prompt.

Partial Sprint

Skip phases when you already have context:

  • "Skip think, I have DESIGN.md" → start from Plan
  • "Just review and ship this branch" → run Review → Test → Ship
  • "I need a design review" → run Phase 2 (Plan) only

Single Phase

Any phase can run standalone:

  • /think — Reframe the problem, challenge assumptions, write DESIGN.md
  • /plan — Architecture, data flow, test strategy, write PLAN.md
  • /build — Implement from PLAN.md
  • /review — Code review with auto-fix for obvious issues
  • /test — Browser testing, regression tests, bug reports
  • /ship — Sync, test, push, open PR

Phase Details

Phase 1: Think (YC Office Hours)

Goal: Reframe the problem before writing code.

Spawn a subagent (Sonnet) with the Think prompt from references/prompts.md. It will:

  1. Ask 6 forcing questions about the real pain, not the feature request
  2. Challenge the framing — "You said X but you actually need Y"
  3. Generate 3 implementation approaches with effort estimates
  4. Recommend the narrowest wedge to ship tomorrow
  5. Write DESIGN.md with the distilled product vision

Key rule: Listen to the pain, not the feature request. The user says "daily briefing app" but means "personal chief of staff AI."

Phase 2: Plan (Eng Manager)

Goal: Lock architecture before building.

Spawn a subagent (Sonnet) with the Plan prompt. It reads DESIGN.md and produces PLAN.md containing:

  1. Architecture diagram (ASCII)
  2. Data flow and state machines
  3. File structure and module boundaries
  4. Test strategy and failure modes
  5. Milestone breakdown (what ships first)

Key rule: No code until the plan is approved. Challenge scope ruthlessly.

Phase 3: Build (Implementer)

Goal: Write code from PLAN.md.

Use the main session or spawn a subagent (Haiku for simple, Sonnet for complex). It reads PLAN.md and:

  1. Implements each milestone in order
  2. Writes tests alongside code (aim for >80% coverage)
  3. Commits atomically per milestone
  4. Updates PLAN.md with implementation notes

Key rule: Follow the plan. If the plan is wrong, update PLAN.md first, then code.

Phase 4: Review (Staff Engineer)

Goal: Find bugs that pass CI but blow up in production.

Spawn a subagent (Sonnet) with the Review prompt. It:

  1. Reads the diff against main/develop
  2. Catches logic errors, race conditions, edge cases
  3. Auto-fixes obvious issues (formatting, unused imports)
  4. Flags completeness gaps and security concerns
  5. Writes a review report

Key rule: Be paranoid. Assume the code will be hit by edge cases tomorrow.

Phase 5: Test (QA Lead)

Goal: Test like a user, not like a developer.

Spawn a subagent (Sonnet) with the Test prompt. It:

  1. Opens the app in a real browser (use browser tool)
  2. Clicks through every user flow
  3. Tests edge cases and error states
  4. Reports bugs with reproduction steps
  5. Auto-fixes and generates regression tests

Key rule: The user doesn't read code. Click the buttons. Break things.

Phase 6: Ship (Release Engineer)

Goal: One command to production.

Run in main session:

  1. Sync with remote (git pull/rebase)
  2. Run full test suite
  3. Audit test coverage
  4. Push and open PR
  5. Update project docs

Key rule: If tests fail, don't ship. Fix first.

Model Selection

Phase Model Why
Think Sonnet Needs judgment to reframe problems
Plan Sonnet Architecture decisions need reasoning
Build Haiku/Sonnet Simple features → Haiku, complex → Sonnet
Review Sonnet Bug detection needs deep analysis
Test Sonnet Browser interaction needs context
Ship Haiku Mechanical execution

Parallel Sprints

For large projects, run multiple sprints on different branches:

  1. Create feature branches for each sprint
  2. Spawn subagents per branch
  3. Each subagent works in isolation
  4. Review and merge sequentially

Max practical parallelism: 3-5 sprints (limited by context management).

Output Files

All phase outputs go to the project root:

  • DESIGN.md — Product vision from Think phase
  • PLAN.md — Architecture and milestones from Plan phase
  • Review reports are written to stdout (capture in conversation)
  • Test reports are written to stdout

Clean up output files after shipping if not needed long-term.

Usage Guidance
Before installing or invoking this skill, consider the following: - This skill will create and modify files (DESIGN.md, PLAN.md, code, tests), make commits, and may push branches and open PRs against your remote repositories. If you don't want automated pushes, restrict the skill to read-only or require manual approval before pushing. - The SKILL.md expects tools and credentials (git, npm/pytest, a browser automation tool, and access to git remotes). The skill does not declare required environment variables for remote auth; it may therefore use any existing credentials configured on the host. Ensure your local git credentials, tokens, or SSH keys are appropriate or run the skill in a sandboxed environment. - Because the skill can auto-fix code and commit changes, review outputs (diffs) before merging or shipping. Configure the agent to request explicit user confirmation for write/push operations if possible. - If you will let it run browser automation, be aware that it can interact with external web UIs and may submit real data; run that step against a development/staging instance when testing. - Recommended mitigations: run the skill on a disposable clone, disable automatic pushing (require manual PR creation), restrict network access or use least-privilege tokens, and review the included prompts and any generated commits before merging. If you want a safer posture, ask the skill to run in 'plan-only' or 'review-only' mode (no commits/pushes) or request an explicit confirmation step before any network or push action.
Capability Analysis
Type: OpenClaw Skill Name: gstack-workflow Version: 1.0.0 The skill bundle implements a structured development workflow (Think, Plan, Build, Review, Test, Ship) inspired by industry best practices. The instructions in SKILL.md and references/prompts.md are clearly aligned with the stated purpose of assisting in software development, including architectural planning, automated testing, and code review. While the workflow involves executing shell commands (git, npm, pytest) and using a browser tool for QA, these actions are contextually appropriate and do not exhibit signs of malicious intent, data exfiltration, or unauthorized access.
Capability Assessment
Purpose & Capability
The name/description match the instructions: it's a 6-phase dev workflow that reads/writes DESIGN.md and PLAN.md, spawns role-based subagents, runs build/test/review/ship steps. No requested env vars or binaries are declared, which is plausible for an instruction-only workflow, but the instructions assume access to git, test runners (npm/pytest), and a 'browser' tool that may not be present.
Instruction Scope
The SKILL.md instructs the agent to run repository-changing actions (implement code, commit per milestone, auto-fix, run git pull/rebase, push, open PRs), to execute tests (npm/pytest), and to open the app in a real browser and click through flows. These actions can read/write project files, interact with remote services, and modify source control. While coherent with the stated purpose, they grant the agent broad write-and-network capabilities and should only be allowed with explicit user consent and appropriate safeguards.
Install Mechanism
Instruction-only skill with no install spec or code files. This is low-risk from an install perspective — nothing is downloaded or written at install time.
Credentials
The skill declares no required credentials, yet the Ship/Review/Test phases imply use of remote git operations, opening PRs, and potentially interacting with external services (CI, hosting, browsers). These operations typically rely on stored credentials (git config, SSH keys, GH_TOKEN, etc.). The absence of declared env vars or explicit instructions for obtaining credentials reduces transparency and could lead to unexpected use of developer credentials already present in the environment.
Persistence & Privilege
always:false (normal). The skill is authorized to run autonomously by default (disable-model-invocation:false), spawn subagents, write files to project root, auto-commit, and (per instructions) push to remotes. These are legitimate for a dev workflow but have meaningful side effects — users should confirm whether the agent may perform network pushes or should be limited to local/dry-run operation.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install gstack-workflow
  3. After installation, invoke the skill by name or use /gstack-workflow
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.0
Initial release: 6-phase structured development sprint inspired by Garry Tan's gstack
Metadata
Slug gstack-workflow
Version 1.0.0
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 1
Frequently Asked Questions

What is GStack Dev Workflow?

Structured development workflow inspired by Garry Tan's gstack. Use when the user wants to build a feature, start a project, do a code review, or ship code w... It is an AI Agent Skill for Claude Code / OpenClaw, with 130 downloads so far.

How do I install GStack Dev Workflow?

Run "/install gstack-workflow" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is GStack Dev Workflow free?

Yes, GStack Dev Workflow is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does GStack Dev Workflow support?

GStack Dev Workflow is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created GStack Dev Workflow?

It is built and maintained by Jahonn Ding (@jahonn); the current version is v1.0.0.

💬 Comments