ワンクリックで
solo-founder-wingman
solo-founder-wingman には rahlplx から収集した 19 個の skills があり、リポジトリ単位の職業カバレッジとサイト内 skill 詳細ページを表示します。
このリポジトリの skills
Run the SHIP checklist (Stable, Hidden secrets, Inputs validated, Performance) immediately before every deploy, using the agent's own tools directly. Use right before any git push to a branch that auto-deploys, after /verify-path and /security-audit have already passed.
Run a short retrospective right after a feature actually ships (post /ship-checklist Green, post-deploy) — capture what worked, what didn't, and any surprise, then feed genuine lessons forward into PRD.md's non-goals or behavior rules. Use once per shipped feature/milestone, not on a calendar cadence (that's /weekly-plan's reconciliation step).
Orient a founder who has never used an AI coding agent (Claude Code, OpenCode, or Codex CLI) before to how the *tool* works, before anything about their product idea comes up. Use this first, before /validate-demand, whenever the founder seems unfamiliar with AI coding agents generally — confused by terminal/CLI concepts, unsure what a "slash command" is, or asking how to talk to the agent at all.
Turn a rough product idea into a structured Founding Prompt using the BRIEF framework, then generate PRD.md, AGENTS.md, and llms.txt from it. Use this once demand is validated (after /validate-demand) and before any prototyping begins.
Reverse-engineer a PRD.md/AGENTS.md from a codebase that already exists (with no PRD, or one from another tool/convention), instead of eliciting from scratch. Use this instead of /validate-demand + /founding-prompt whenever a project already has code before founder-os is installed.
Commit in small, atomic "save points" (roughly one logical change each) during any non-trivial task, so a broken step is one git revert/reset away from a known-good state instead of losing a whole session's progress. Use during any multi-step build/fix/refactor, not just at the end.
Produce a structured handoff summary before a session ends with unfinished work, right before /compact or /clear, or whenever /hire-agent hands a task to a different role — so in-progress state, what's actually been verified, and what's still open survive the boundary instead of being silently re-derived or dropped.
Run the 3-Layer Review (you: visual/functional check, a second AI: code quality, a security-focused AI: vulnerabilities), and be explicit about the limits of same-model-family review. Use after any major feature; for anything security-critical, pair with /security-audit.
Map a product into Pages/Database/Auth/API/Integrations blocks using the LEGO framework, then write the results into PRD.md's Data model and Integrations sections. Use after /founding-prompt and before first prototyping, and again whenever a major feature changes the data model.
Answer "what has the safety layer actually blocked or asked about?" by reading and summarizing the audit log in plain English. Use whenever the founder asks what's been happening, after a stretch of active work, or periodically as a trust check — since the founder can't read policy.json or the hook code themselves.
Diagnose and fix a bug using the SEB method (Screenshot, Error message, Before/After) plus the bisect trick for unknown regressions, gathering real evidence before guessing at a fix. This is the fuller version of /fix-bug — use directly for trickier bugs or when the quick pass doesn't find the cause.
Decide which engineering role (PM/Design/Frontend/Backend/DevOps/QA) the agent should act as for a given task, using the HIRE framework (Hire the right agent, Instruct clearly, Review output, Evolve with feedback). Use before instructing the agent on any non-trivial task, and whenever work switches between UI, backend logic, and review.
Connect a third-party service (payments, email, storage, analytics) using the PLUG framework (Pick/Look/Use AI/Guard the keys), preferring the MCP servers already configured in .mcp.json over ad hoc API wiring. Use whenever /map-architecture identifies an integration, or the founder asks to "add" a service.
Diagnose whether an area of code has real technical debt using the smell-test warning signs, then refactor it safely without changing user-facing behavior. This is the fuller diagnostic version of /refactor-cleanup — use this when it's unclear whether or where to refactor, not just to run the cleanup itself.
Audit the product against the LOCK checklist (Login secure, Only authorized access, Clean inputs, Keys hidden), cross-checked against policy.json's actually-enforced rules, not just the abstract framework. Run before any deploy (pair with /ship-checklist), monthly, and whenever /multi-model-review flags something security-critical.
Calibrate the agent's output using founder-provided visual references (screenshots, competitor flows, brand examples) via the SHOW method (Sample, Highlight, Omit, Want), rather than describing desired output in words alone. Use whenever a founder has or can get a reference, before /add-page or other UI work.
Sanity-check whether a product idea has real demand before any prompting or building starts, using the Jobs-to-be-Done framing and lightweight market-research techniques. Use this first, before /founding-prompt.
Gate any "this is done" claim behind actual evidence using the PATH walkthrough method (Primary flow, Alternate paths, Transitions, Happy+Hostile testing), since the founder cannot read the code to verify it themselves. Run this before presenting any feature as complete, and before /ship-checklist.
Turn an unstructured backlog into a weekly plan of 3 features to build, 3 bugs to fix, and 3 users to talk to, using the 3-3-3 method. Use at the start of each work week, especially when the founder has more ideas than a week can hold.