Skip to content

Slash Command Development Pipeline

by Zevi Arnovitz on January 18, 2026

Zevi Arnovitz's AI-Powered Product Development Workflow for Non-Technical PMs

Zevi Arnovitz, a non-technical PM at Meta, has developed a sophisticated workflow that allows him to build functional products without coding knowledge. His system uses AI tools like Claude Code and Cursor to transform product ideas into working features through a structured pipeline of slash commands.

The Core Workflow Pipeline

  1. Create Issue - Quickly capture ideas and bugs

    • Use /create_issue to document feature ideas or bugs in Linear
    • Focuses on capturing just enough information to return to later
    • Allows you to continue working without losing your train of thought
  2. Exploration Phase - Understand the problem deeply

    • Use /exploration_phase to analyze the issue with Claude
    • AI reads the codebase to understand current implementation
    • Asks clarifying questions about requirements and constraints
    • Identifies key areas of the codebase that will need modification
  3. Create Plan - Develop a structured implementation approach

    • Use /create_plan to generate a markdown file with implementation steps
    • Includes TLDR summary, critical decisions, and task breakdown
    • Creates a plan that can be shared between different AI models
    • Adds status trackers to each task for progress monitoring
  4. Execute Plan - Build the actual feature

    • Use /execute_plan to implement the code according to the plan
    • Different models can be used for different aspects (e.g., Gemini for UI)
    • Maintains a structured approach to implementation
    • Allows for iterative development and testing
  5. Review - Evaluate the implementation

    • Use /review to have Claude review its own code
    • Identifies bugs and issues at different severity levels
    • Provides a first pass at quality control
  6. Peer Review - Get multiple perspectives

    • Use multiple AI models to review the same code
    • Each model has different strengths and catches different issues
    • Use /peer_review to have models evaluate each other's feedback
    • Creates a "team" of AI reviewers with different perspectives
  7. Update Documentation - Improve for future development

    • Update documentation based on what was learned
    • Helps future AI interactions understand the codebase better
    • Creates a virtuous cycle of improvement

Key Principles for Working with AI as a Non-Technical PM

Continuous Learning

  • Use /learning_opportunity to understand technical concepts
  • Ask the AI to explain complex topics using the 80/20 rule
  • View each project as "tuition" for developing your skills
  • Gradually increase technical exposure through a progression of tools

Model Selection Strategy

  • Different AI models have different strengths:
    • Claude: Communicative, thoughtful, good for planning and exploration
    • GPT/Codex: Excellent problem-solver but less communicative
    • Gemini: Strong at UI/design but can be unpredictable

Prompt Improvement Process

  • When AI makes mistakes, ask "what in your system prompt made you make this mistake?"
  • Update prompts and documentation based on failures
  • Create a continuous improvement cycle for your AI tools
  • Turn repetitive interactions into slash commands

Gradual Technical Progression

  • Start with ChatGPT projects (friendly UI, less code exposure)
  • Graduate to Lovable/Bolt/Replit (more code but still guided)
  • Eventually move to Cursor/Claude Code (full code environment)
  • Treat code exposure like "exposure therapy" - gradually increase comfort

Applications Beyond Side Projects

  • For company work:

    • Make codebases "AI-native" with good documentation
    • Focus on contained UI projects rather than database migrations
    • Use as a collaborative learning opportunity with dev teams
    • Create PRs for devs to review and finalize
  • For career development:

    • Create AI coaching projects for interview preparation
    • Use AI for mock interviews and feedback
    • Build tools to practice specific skills you're weak in
    • Focus on being a "10x learner" rather than a "10x PM"

The workflow represents a shift in how non-technical people can contribute to product development, potentially collapsing traditional role boundaries as more people become builders regardless of technical background.