Pack Hub

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.

Turns any raw capture — forwarded emails, quick notes, meeting transcripts, or recordings — into structured next actions. Extracts and classifies every item, generates draft replies and summaries, creates Epismo tracks for tasks, saves decisions and references as context packs, then routes outputs to the right people and channels.

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.

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.

A fat, AI ready playbook for running product discovery end to end. Based on the pm skills methodology (Teresa Torres' Continuous Discovery Habits, The Mom Test, Lean Startup pretotyping). Use this as an operating guide — not a summary. Each block tells you what to do, what inputs to gather, how to reason, how to judge quality, and what artifact to produce. Work through blocks in order for a full discovery cycle, or jump to a specific block when you need a targeted sub skill.