Pack Hub

Purpose Prepare for, run, and advance an enterprise discovery opportunity through a concrete Codex + ChatGPT + sales representative operating loop. The playbook turns account research, call preparation, rehearsal, live discovery, and follow through into five linked tasks with clear artifacts and approval gates. When to use Use this playbook before and immediately after an enterprise discovery call when the outcome depends on multiple stakeholders, a defined buying process, technical validation, or a cross functional pilot. Role design Codex recovers account context, converts it into a discovery plan, captures the post call outcome, and prepares the follow up and CRM update proposal. ChatGPT runs the account specific role play in a separate text or Voice Mode session. Sales representative leads the customer conversation and owns customer commitments. Human approval is required before any external follow up or CRM change. What you need A named account and a sales representative Any available CRM opportunity, account history, prior interactions, and internal notes An account specific ChatGPT role play context for Step 3 A recording, transcript, or reliable notes after the customer meeting When a source is missing, Codex records the gap as an open question rather than filling it with an assumption. How to run it Materialize the workflow as a tracked run and map human to the sales representative. The run creates a root goal and five dependent tasks. Codex and ChatGPT steps are assigned to their respective agents; use the generated task IDs for logs and status changes, rather than reusing the workflow alias as a task reference. Guardrails Keep facts, assumptions, and unknowns distinct. Do not present ChatGPT role play statements or unverified research as customer confirmation. Do not send follow ups or modify a CRM without explicit human approval. Do not mark a task done merely because a draft exists; satisfy its completion condition. If no customer owner or date is agreed, preserve the gap as an unresolved item. Close and improve Close the root goal only when the call is captured, approval status is explicit, and the next step has an owner and date. After a completed run, have Codex generate an Epismo track review, send any concrete improvement as workflow feedback, and rate the workflow according to its actual outcome.

Small Feature Ship Workflow A reusable workflow for shipping small product or engineering features with minimal human coordination and clear agent ownership. This workflow is optimized for small, bounded changes where the goal is to avoid process overhead while still protecting product judgment, implementation quality, and release safety. How to Use When a user makes a small feature/change request in chat, treat this workflow as the operating procedure and execute s001 → s004 in the same chat session. Intermediate artifacts (decision brief, adversarial review prompt, Codex verdict) live in the chat context — no external persistence needed. The final deliverable returned to the user in chat is the PR URL . Role Map | Role | Assignee | Responsibility | | | | | | Feature Owner | human | Owns intent, final judgment, and shipping decision. | | Decision Challenger | Claude Code | Challenges whether the feature should be built, whether the proposed solution is the right one, and what the real problem is. | | Builder | Claude Code | Implements the agreed solution, opens the PR. | | Reviewer | Codex (preferred) / Claude Code (fallback) | Adversarially reviews the PR. Codex owns the verdict when available; otherwise Claude Code performs the same adversarial review against its own work. | | Shipper | human | Reviews the PR, merges/releases, and observes early results. | Core Loop Decide → Build → Check → Ship Four steps. Each step has a clear owner, with explicit handoff artifacts so the next owner can proceed without ambiguity. Operating Principle Do not move forward simply because a feature request exists. The first step must pressure test the request — but right size the scrutiny to the change . A variable rename does not deserve a 9 point brief; a behavior change with user impact does. The Decide step defines what "enough scrutiny" looks like for each tier.

A repeatable daily rhythm for solopreneurs and operators using Claude Code as an always on chief of staff. Inspired by Jim Prosser (@jimprosser): "My chief of staff, Claude Code". When to use: Every working day. Adapt the cadence to your schedule. Preconditions: Claude Code is configured with access to your calendar, task list, and inbox (via MCP servers or file based context) A CONTEXT.md or equivalent daily state file is maintained in your working directory You have a GOALS.md file Claude Code references for alignment

This workflow works with any coding agent that supports Skills, file access, shell commands, and GitHub operations. This workflow turns raw bug reports from a Discord channel into a continuous improvement loop for your product. A lightweight bot converts reports into structured GitHub Issues, a triage skill reads each need triage Issue and labels it as auto fix or manual fix, and an auto fix skill takes auto fix Issues, inspects the codebase, applies small focused changes, runs tests, and opens review ready pull requests. Engineers stay in control through labels and normal code review, while the system quietly handles the repetitive work of sorting bugs and drafting fixes, so the product keeps getting better from real user feedback with less manual overhead.

A pack for organizing the inside of a hard decision. Not for judging whether the decision is right — for making the shape of the decision visible so the person can decide for themselves. Why this pack exists Most decisions feel hard not because the answer is genuinely difficult, but because everything is tangled. The choices, the reasons behind each choice, what is known versus assumed, what is reversible versus permanent, what is being avoided by not deciding — all of these sit in the same fog at once. The fog is the problem, not the choice. This pack pulls each strand out of the fog and lays it on the table. By the end, the person sees their decision the way an outside observer would: choices named, beliefs labeled, regrets imagined, costs of waiting acknowledged. Often the answer becomes obvious once the picture is clear. When it doesn't, at least the person knows exactly what they are uncertain about, and what would change their mind. Core stance The assistant is a structuring partner, not a judge. The pack does not produce a verdict. It produces a clear page that the person walks away holding. Whether they decide today, next week, or never is their business — the assistant's job is to make sure the shape of the situation is no longer hidden from them. Who this is for Anyone facing a decision that has been sitting unresolved — a career move, a hire or fire, a pivot, a price change, an investment, a relationship choice, whether to keep or kill a project, whether to take an opportunity. Works for personal and professional decisions, big and small. How this differs from "Idea Stress Test" Idea Stress Test asks "is this worth building?" and presses hard for a verdict. Decision Clarifier asks "what actually is this decision?" and stays neutral. Use Idea Stress Test when the user is pitching an idea and wants pressure. Use Decision Clarifier when the user is stuck and wants clarity. When to use it Load this pack when the user signals stuckness around a choice: "I can't decide whether to...", "I'm torn between...", "I keep going back and forth on...", "should I...", "I've been sitting on this for weeks." Also useful when someone is about to make a quick decision and you want to slow them down enough to see what they're actually choosing. When not to use it Do not load when the decision is already made and the person just needs help executing. Do not load when the person is clearly venting and not seeking structure. Do not load when the question is factual ("which framework should I use?") rather than a real choice with stakes. Expected duration 15–30 minutes of dialogue. Output is a one page summary of the decision's shape. The user keeps it, returns to it, updates it. This pack is designed to be re runnable on the same decision as new information arrives.

A pressure test for an unvalidated idea before any building begins. Six forcing questions, asked one at a time, that surface hidden assumptions, refuse polite agreement, and convert vague conviction into a small, falsifiable next step. Why this pack exists Most ideas die from unexamined assumptions, not from bad execution. When a builder pitches an idea — to a friend, a partner, an AI assistant — the default response is some version of "interesting!" That politeness is the most expensive thing in early stage product work. It lets bad ideas survive long enough to consume months of building. This pack replaces the polite mirror with a structured interrogation. The six questions are sequenced so each one closes off a common escape route: vague users, hypothetical workarounds, missing "why now," unexamined beliefs, optimism bias, and the urge to start coding instead of testing. Core idea Specificity is the evidence of understanding. A builder who can name one real person, one real moment, and one real workaround has done the work. A builder who speaks in plurals and abstractions has not. Every question in this pack pushes relentlessly toward the singular and concrete. Who this is for Anyone holding an idea that has not yet met reality — solo builders, side project starters, founders early in formation, internal product owners pitching a new initiative. Not for products that already have paying customers. Not for technical implementation questions. Not for emotional support sessions. When to use it Load this pack when the user signals an unvalidated idea: "I'm thinking about building...", "is this worth doing?", "what do you think of this?", or any pitch of a half formed concept. Do not load when there are already paying customers, when the question is about implementation, when the user is venting, when the decision is irreversible, or when this same idea has been stress tested in a recent session. Expected duration 20–40 minutes of back and forth. Faster usually means worse. The output is a written diagnostic with a single verdict: GO, VERIFY, RECONSIDER, or KILL — plus a 7 day falsifiable test.

An account specific buyer simulator for rehearsing enterprise discovery by text or voice. It is fictional training material: use it to practice question quality, business impact discovery, stakeholder mapping, objection diagnosis, and a mutual next step—not to validate a real account or product claim. Modes Role play mode: the assistant adopts the buyer role and makes the seller earn information. Debrief mode: after the seller explicitly ends the role play, the assistant becomes a precise sales coach and evaluates only what happened in the conversation. Replay mode: re run the weakest moment immediately with the same buyer and a slightly different objection. Default to Intermediate difficulty unless the seller requests another level.

A fat, AI ready playbook for turning a product, feature, or pricing change into coordinated market traction. Based on the pm skills GTM methodology: beachhead segment selection, ICP definition, positioning, message architecture, channel strategy, competitive enablement, and post launch learning. The emphasis is on focused launch choices and explicit trade offs — not broad marketing checklists. Each block is a step in the GTM lifecycle.