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...

Security Scan

The skill is a coherent, instruction-only development workflow, but it implicitly expects privileges and tools (git remotes, browser automation, pushing PRs) without declaring required credentials or runtime capabilities — users should be cautious before letting it modify or push code.

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.

What to consider before installing

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.

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.