{"id":"a34a278d-db7b-4356-bb4e-1982d4d1a295","shortId":"GUp7j5","kind":"skill","title":"plan-eng-review","tagline":"Eng manager-mode plan review. Lock in the execution plan — architecture,\ndata flow, diagrams, edge cases, test coverage, performance. Walks through\nissues interactively with opinionated recommendations. Use when asked to\n\"review the architecture\", \"engineering review\", or \"lock i","description":"## Preamble\n\n```bash\neval \"$(~/.vibestack/bin/vibe-slug 2>/dev/null)\" 2>/dev/null || SLUG=\"unknown\"\n_LEARN_FILE=\"${VIBESTACK_HOME:-$HOME/.vibestack}/projects/${SLUG:-unknown}/learnings.jsonl\"\nif [ -f \"$_LEARN_FILE\" ]; then\n  _LEARN_COUNT=$(wc -l < \"$_LEARN_FILE\" 2>/dev/null | tr -d ' ')\n  echo \"LEARNINGS: $_LEARN_COUNT entries loaded\"\n  if [ \"$_LEARN_COUNT\" -gt 5 ] 2>/dev/null; then\n    ~/.vibestack/bin/vibe-learnings-search --limit 5 2>/dev/null || true\n  fi\nelse\n  echo \"LEARNINGS: none yet\"\nfi\n```\n\n## Priority hierarchy\nIf the user asks you to compress or the system triggers context compaction: Step 0 > Test diagram > Opinionated recommendations > Everything else. Never skip Step 0 or the test diagram. Do not preemptively warn about context limits -- the system handles compaction automatically.\n\n## My engineering preferences (use these to guide your recommendations):\n* DRY is important—flag repetition aggressively.\n* Well-tested code is non-negotiable; I'd rather have too many tests than too few.\n* I want code that's \"engineered enough\" — not under-engineered (fragile, hacky) and not over-engineered (premature abstraction, unnecessary complexity).\n* I err on the side of handling more edge cases, not fewer; thoughtfulness > speed.\n* Bias toward explicit over clever.\n* Right-sized diff: favor the smallest diff that cleanly expresses the change ... but don't compress a necessary rewrite into a minimal patch. If the existing foundation is broken, say \"scrap it and do this instead.\"\n\n## Cognitive Patterns — How Great Eng Managers Think\n\nThese are not additional checklist items. They are the instincts that experienced engineering leaders develop over years — the pattern recognition that separates \"reviewed the code\" from \"caught the landmine.\" Apply them throughout your review.\n\n1. **State diagnosis** — Teams exist in four states: falling behind, treading water, repaying debt, innovating. Each demands a different intervention (Larson, An Elegant Puzzle).\n2. **Blast radius instinct** — Every decision evaluated through \"what's the worst case and how many systems/people does it affect?\"\n3. **Boring by default** — \"Every company gets about three innovation tokens.\" Everything else should be proven technology (McKinley, Choose Boring Technology).\n4. **Incremental over revolutionary** — Strangler fig, not big bang. Canary, not global rollout. Refactor, not rewrite (Fowler).\n5. **Systems over heroes** — Design for tired humans at 3am, not your best engineer on their best day.\n6. **Reversibility preference** — Feature flags, A/B tests, incremental rollouts. Make the cost of being wrong low.\n7. **Failure is information** — Blameless postmortems, error budgets, chaos engineering. Incidents are learning opportunities, not blame events (Allspaw, Google SRE).\n8. **Org structure IS architecture** — Conway's Law in practice. Design both intentionally (Skelton/Pais, Team Topologies).\n9. **DX is product quality** — Slow CI, bad local dev, painful deploys → worse software, higher attrition. Developer experience is a leading indicator.\n10. **Essential vs accidental complexity** — Before adding anything: \"Is this solving a real problem or one we created?\" (Brooks, No Silver Bullet).\n11. **Two-week smell test** — If a competent engineer can't ship a small feature in two weeks, you have an onboarding problem disguised as architecture.\n12. **Glue work awareness** — Recognize invisible coordination work. Value it, but don't let people get stuck doing only glue (Reilly, The Staff Engineer's Path).\n13. **Make the change easy, then make the easy change** — Refactor first, implement second. Never structural + behavioral changes simultaneously (Beck).\n14. **Own your code in production** — No wall between dev and ops. \"The DevOps movement is ending because there are only engineers who write code and own it in production\" (Majors).\n15. **Error budgets over uptime targets** — SLO of 99.9% = 0.1% downtime *budget to spend on shipping*. Reliability is resource allocation (Google SRE).\n\nWhen evaluating architecture, think \"boring by default.\" When reviewing tests, think \"systems over heroes.\" When assessing complexity, ask Brooks's question. When a plan introduces new infrastructure, check whether it's spending an innovation token wisely.\n\n## Documentation and diagrams:\n* I value ASCII art diagrams highly — for data flow, state machines, dependency graphs, processing pipelines, and decision trees. Use them liberally in plans and design docs.\n* For particularly complex designs or behaviors, embed ASCII diagrams directly in code comments in the appropriate places: Models (data relationships, state transitions), Controllers (request flow), Concerns (mixin behavior), Services (processing pipelines), and Tests (what's being set up and why) when the test structure is non-obvious.\n* **Diagram maintenance is part of the change.** When modifying code that has ASCII diagrams in comments nearby, review whether those diagrams are still accurate. Update them as part of the same commit. Stale diagrams are worse than no diagrams — they actively mislead. Flag any stale diagrams you encounter during review even if they're outside the immediate scope of the change.\n\n## BEFORE YOU START:\n\n### Design Doc Check\n```bash\nsetopt +o nomatch 2>/dev/null || true  # zsh compat\nSLUG=$(~/.claude/skills/browse/bin/remote-slug 2>/dev/null || basename \"$(git rev-parse --show-toplevel 2>/dev/null || pwd)\")\nBRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')\nDESIGN=$(ls -t ~/.vibestack/projects/$SLUG/*-$BRANCH-design-*.md 2>/dev/null | head -1)\n[ -z \"$DESIGN\" ] && DESIGN=$(ls -t ~/.vibestack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1)\n[ -n \"$DESIGN\" ] && echo \"Design doc found: $DESIGN\" || echo \"No design doc found\"\n```\nIf a design doc exists, read it. Use it as the source of truth for the problem statement, constraints, and chosen approach. If it has a `Supersedes:` field, note that this is a revised design — check the prior version for context on what changed and why.\n\n## Prerequisite Skill Offer\n\nWhen the design doc check above prints \"No design doc found,\" offer the prerequisite\nskill before proceeding.\n\nSay to the user via AskUserQuestion:\n\n> \"No design doc found for this branch. `/office-hours` produces a structured problem\n> statement, premise challenge, and explored alternatives — it gives this review much\n> sharper input to work with. Takes about 10 minutes. The design doc is per-feature,\n> not per-product — it captures the thinking behind this specific change.\"\n\nOptions:\n- A) Run /office-hours now (we'll pick up the review right after)\n- B) Skip — proceed with standard review\n\nIf they skip: \"No worries — standard review. If you ever want sharper input, try\n/office-hours first next time.\" Then proceed normally. Do not re-offer later in the session.\n\nIf they choose A:\n\nSay: \"Running /office-hours inline. Once the design doc is ready, I'll pick up\nthe review right where we left off.\"\n\nRead the `/office-hours` skill file at `~/.claude/skills/office-hours/SKILL.md` using the Read tool.\n\n**If unreadable:** Skip with \"Could not load /office-hours — skipping.\" and continue.\n\nFollow its instructions from top to bottom, **skipping these sections** (already handled by the parent skill):\n- Preamble (run first)\n- AskUserQuestion Format\n- Completeness Principle — Boil the Lake\n- Search Before Building\n- Contributor Mode\n- Completion Status Protocol\n- Telemetry (run last)\n- Step 0: Detect platform and base branch\n- Review Readiness Dashboard\n- Plan File Review Report\n- Prerequisite Skill Offer\n- Plan Status Footer\n\nExecute every other section at full depth. When the loaded skill's instructions are complete, continue with the next step below.\n\nAfter /office-hours completes, re-run the design doc check:\n```bash\nsetopt +o nomatch 2>/dev/null || true  # zsh compat\nSLUG=$(~/.claude/skills/browse/bin/remote-slug 2>/dev/null || basename \"$(git rev-parse --show-toplevel 2>/dev/null || pwd)\")\nBRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null | tr '/' '-' || echo 'no-branch')\nDESIGN=$(ls -t ~/.vibestack/projects/$SLUG/*-$BRANCH-design-*.md 2>/dev/null | head -1)\n[ -z \"$DESIGN\" ] && DESIGN=$(ls -t ~/.vibestack/projects/$SLUG/*-design-*.md 2>/dev/null | head -1)\n[ -n \"$DESIGN\" ] && echo \"Design doc found: $DESIGN\" || echo \"No design doc found\"\n```\n\nIf a design doc is now found, read it and continue the review.\nIf none was produced (user may have cancelled), proceed with standard review.\n\n### Step 0: Scope Challenge\nBefore reviewing anything, answer these questions:\n1. **What existing code already partially or fully solves each sub-problem?** Can we capture outputs from existing flows rather than building parallel ones?\n2. **What is the minimum set of changes that achieves the stated goal?** Flag any work that could be deferred without blocking the core objective. Be ruthless about scope creep.\n3. **Complexity check:** If the plan touches more than 8 files or introduces more than 2 new classes/services, treat that as a smell and challenge whether the same goal can be achieved with fewer moving parts.\n4. **Search check:** For each architectural pattern, infrastructure component, or concurrency approach the plan introduces:\n   - Does the runtime/framework have a built-in? Search: \"{framework} {pattern} built-in\"\n   - Is the chosen approach current best practice? Search: \"{pattern} best practice {current year}\"\n   - Are there known footguns? Search: \"{framework} {pattern} pitfalls\"\n\n   If WebSearch is unavailable, skip this check and note: \"Search unavailable — proceeding with in-distribution knowledge only.\"\n\n   If the plan rolls a custom solution where a built-in exists, flag it as a scope reduction opportunity. Annotate recommendations with **[Layer 1]**, **[Layer 2]**, **[Layer 3]**, or **[EUREKA]** (see preamble's Search Before Building section). If you find a eureka moment — a reason the standard approach is wrong for this case — present it as an architectural insight.\n5. **TODOS cross-reference:** Read `TODOS.md` if it exists. Are any deferred items blocking this plan? Can any deferred items be bundled into this PR without expanding scope? Does this plan create new work that should be captured as a TODO?\n\n5. **Completeness check:** Is the plan doing the complete version or a shortcut? With AI-assisted coding, the cost of completeness (100% test coverage, full edge case handling, complete error paths) is 10-100x cheaper than with a human team. If the plan proposes a shortcut that saves human-hours but only saves minutes with Claude Code + vibestack, recommend the complete version. Boil the lake.\n\n6. **Distribution check:** If the plan introduces a new artifact type (CLI binary, library package, container image, mobile app), does it include the build/publish pipeline? Code without distribution is code nobody can use. Check:\n   - Is there a CI/CD workflow for building and publishing the artifact?\n   - Are target platforms defined (linux/darwin/windows, amd64/arm64)?\n   - How will users download or install it (GitHub Releases, package manager, container registry)?\n   If the plan defers distribution, flag it explicitly in the \"NOT in scope\" section — don't let it silently drop.\n\nIf the complexity check triggers (8+ files or 2+ new classes/services), proactively recommend scope reduction via AskUserQuestion — explain what's overbuilt, propose a minimal version that achieves the core goal, and ask whether to reduce or proceed as-is. If the complexity check does not trigger, present your Step 0 findings and proceed directly to Section 1.\n\nAlways work through the full interactive review: one section at a time (Architecture → Code Quality → Tests → Performance) with at most 8 top issues per section.\n\n**Critical: Once the user accepts or rejects a scope reduction recommendation, commit fully.** Do not re-argue for smaller scope during later review sections. Do not silently reduce scope or skip planned components.\n\n## Review Sections (after scope is agreed)\n\n**Anti-skip rule:** Never condense, abbreviate, or skip any review section (1-4) regardless of plan type (strategy, spec, code, infra). Every section in this skill exists for a reason. \"This is a strategy doc so implementation sections don't apply\" is always wrong — implementation details are where strategy breaks down. If a section genuinely has zero findings, say \"No issues found\" and move on — but you must evaluate it.\n\n{{include lib/snippets/prior-learnings.md}}\n### 1. Architecture review\nEvaluate:\n* Overall system design and component boundaries.\n* Dependency graph and coupling concerns.\n* Data flow patterns and potential bottlenecks.\n* Scaling characteristics and single points of failure.\n* Security architecture (auth, data access, API boundaries).\n* Whether key flows deserve ASCII diagrams in the plan or in code comments.\n* For each new codepath or integration point, describe one realistic production failure scenario and whether the plan accounts for it.\n* **Distribution architecture:** If this introduces a new artifact (binary, package, container), how does it get built, published, and updated? Is the CI/CD pipeline part of the plan or deferred?\n\n**STOP.** For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.\n\n## Confidence Calibration\n\nEvery finding MUST include a confidence score (1-10):\n\n| Score | Meaning | Display rule |\n|-------|---------|-------------|\n| 9-10 | Verified by reading specific code. Concrete bug or exploit demonstrated. | Show normally |\n| 7-8 | High confidence pattern match. Very likely correct. | Show normally |\n| 5-6 | Moderate. Could be a false positive. | Show with caveat: \"Medium confidence, verify this is actually an issue\" |\n| 3-4 | Low confidence. Pattern is suspicious but may be fine. | Suppress from main report. Include in appendix only. |\n| 1-2 | Speculation. | Only report if severity would be P0. |\n\n**Finding format:**\n\n\\`[SEVERITY] (confidence: N/10) file:line — description\\`\n\nExample:\n\\`[P1] (confidence: 9/10) app/models/user.rb:42 — SQL injection via string interpolation in where clause\\`\n\\`[P2] (confidence: 5/10) app/controllers/api/v1/users_controller.rb:18 — Possible N+1 query, verify with production logs\\`\n\n**Calibration learning:** If you report a finding with confidence < 7 and the user\nconfirms it IS a real issue, that is a calibration event. Your initial confidence was\ntoo low. Log the corrected pattern as a learning so future reviews catch it with\nhigher confidence.\n\n### 2. Code quality review\nEvaluate:\n* Code organization and module structure.\n* DRY violations—be aggressive here.\n* Error handling patterns and missing edge cases (call these out explicitly).\n* Technical debt hotspots.\n* Areas that are over-engineered or under-engineered relative to my preferences.\n* Existing ASCII diagrams in touched files — are they still accurate after this change?\n\n**STOP.** For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.\n\n### 3. Test review\n\n100% coverage is the goal. Evaluate every codepath in the plan and ensure the plan includes tests for each one. If the plan is missing tests, add them — the plan should be complete enough that implementation includes full test coverage from the start.\n\n### Test Framework Detection\n\nBefore analyzing coverage, detect the project's test framework:\n\n1. **Read CLAUDE.md** — look for a `## Testing` section with test command and framework name. If found, use that as the authoritative source.\n2. **If CLAUDE.md has no testing section, auto-detect:**\n\n```bash\nsetopt +o nomatch 2>/dev/null || true  # zsh compat\n# Detect project runtime\n[ -f Gemfile ] && echo \"RUNTIME:ruby\"\n[ -f package.json ] && echo \"RUNTIME:node\"\n[ -f requirements.txt ] || [ -f pyproject.toml ] && echo \"RUNTIME:python\"\n[ -f go.mod ] && echo \"RUNTIME:go\"\n[ -f Cargo.toml ] && echo \"RUNTIME:rust\"\n# Check for existing test infrastructure\nls jest.config.* vitest.config.* playwright.config.* cypress.config.* .rspec pytest.ini phpunit.xml 2>/dev/null\nls -d test/ tests/ spec/ __tests__/ cypress/ e2e/ 2>/dev/null\n```\n\n3. **If no framework detected:** still produce the coverage diagram, but skip test generation.\n\n**Step 1. Trace every codepath in the plan:**\n\nRead the plan document. For each new feature, service, endpoint, or component described, trace how data will flow through the code — don't just list planned functions, actually follow the planned execution:\n\n1. **Read the plan.** For each planned component, understand what it does and how it connects to existing code.\n2. **Trace data flow.** Starting from each entry point (route handler, exported function, event listener, component render), follow the data through every branch:\n   - Where does input come from? (request params, props, database, API call)\n   - What transforms it? (validation, mapping, computation)\n   - Where does it go? (database write, API response, rendered output, side effect)\n   - What can go wrong at each step? (null/undefined, invalid input, network failure, empty collection)\n3. **Diagram the execution.** For each changed file, draw an ASCII diagram showing:\n   - Every function/method that was added or modified\n   - Every conditional branch (if/else, switch, ternary, guard clause, early return)\n   - Every error path (try/catch, rescue, error boundary, fallback)\n   - Every call to another function (trace into it — does IT have untested branches?)\n   - Every edge: what happens with null input? Empty array? Invalid type?\n\nThis is the critical step — you're building a map of every line of code that can execute differently based on input. Every branch in this diagram needs a test.\n\n**Step 2. Map user flows, interactions, and error states:**\n\nCode coverage isn't enough — you need to cover how real users interact with the changed code. For each changed feature, think through:\n\n- **User flows:** What sequence of actions does a user take that touches this code? Map the full journey (e.g., \"user clicks 'Pay' → form validates → API call → success/failure screen\"). Each step in the journey needs a test.\n- **Interaction edge cases:** What happens when the user does something unexpected?\n  - Double-click/rapid resubmit\n  - Navigate away mid-operation (back button, close tab, click another link)\n  - Submit with stale data (page sat open for 30 minutes, session expired)\n  - Slow connection (API takes 10 seconds — what does the user see?)\n  - Concurrent actions (two tabs, same form)\n- **Error states the user can see:** For every error the code handles, what does the user actually experience?\n  - Is there a clear error message or a silent failure?\n  - Can the user recover (retry, go back, fix input) or are they stuck?\n  - What happens with no network? With a 500 from the API? With invalid data from the server?\n- **Empty/zero/boundary states:** What does the UI show with zero results? With 10,000 results? With a single character input? With maximum-length input?\n\nAdd these to your diagram alongside the code branches. A user flow with no test is just as much a gap as an untested if/else.\n\n**Step 3. Check each branch against existing tests:**\n\nGo through your diagram branch by branch — both code paths AND user flows. For each one, search for a test that exercises it:\n- Function `processPayment()` → look for `billing.test.ts`, `billing.spec.ts`, `test/billing_test.rb`\n- An if/else → look for tests covering BOTH the true AND false path\n- An error handler → look for a test that triggers that specific error condition\n- A call to `helperFn()` that has its own branches → those branches need tests too\n- A user flow → look for an integration or E2E test that walks through the journey\n- An interaction edge case → look for a test that simulates the unexpected action\n\nQuality scoring rubric:\n- ★★★  Tests behavior with edge cases AND error paths\n- ★★   Tests correct behavior, happy path only\n- ★    Smoke test / existence check / trivial assertion (e.g., \"it renders\", \"it doesn't throw\")\n\n### E2E Test Decision Matrix\n\nWhen checking each branch, also determine whether a unit test or E2E/integration test is the right tool:\n\n**RECOMMEND E2E (mark as [→E2E] in the diagram):**\n- Common user flow spanning 3+ components/services (e.g., signup → verify email → first login)\n- Integration point where mocking hides real failures (e.g., API → queue → worker → DB)\n- Auth/payment/data-destruction flows — too important to trust unit tests alone\n\n**RECOMMEND EVAL (mark as [→EVAL] in the diagram):**\n- Critical LLM call that needs a quality eval (e.g., prompt change → test output still meets quality bar)\n- Changes to prompt templates, system instructions, or tool definitions\n\n**STICK WITH UNIT TESTS:**\n- Pure function with clear inputs/outputs\n- Internal helper with no side effects\n- Edge case of a single function (null input, empty array)\n- Obscure/rare flow that isn't customer-facing\n\n### REGRESSION RULE (mandatory)\n\n**IRON RULE:** When the coverage audit identifies a REGRESSION — code that previously worked but the diff broke — a regression test is added to the plan as a critical requirement. No AskUserQuestion. No skipping. Regressions are the highest-priority test because they prove something broke.\n\nA regression is when:\n- The diff modifies existing behavior (not new code)\n- The existing test suite (if any) doesn't cover the changed path\n- The change introduces a new failure mode for existing callers\n\nWhen uncertain whether a change is a regression, err on the side of writing the test.\n\n**Step 4. Output ASCII coverage diagram:**\n\nInclude BOTH code paths and user flows in the same diagram. Mark E2E-worthy and eval-worthy paths:\n\n```\nCODE PATHS                                            USER FLOWS\n[+] src/services/billing.ts                           [+] Payment checkout\n  ├── processPayment()                                  ├── [★★★ TESTED] Complete purchase — checkout.e2e.ts:15\n  │   ├── [★★★ TESTED] happy + declined + timeout      ├── [GAP] [→E2E] Double-click submit\n  │   ├── [GAP]         Network timeout                 └── [GAP]        Navigate away mid-payment\n  │   └── [GAP]         Invalid currency\n  └── refundPayment()                                 [+] Error states\n      ├── [★★  TESTED] Full refund — :89                ├── [★★  TESTED] Card declined message\n      └── [★   TESTED] Partial (non-throw only) — :101  └── [GAP]        Network timeout UX\n\nLLM integration: [GAP] [→EVAL] Prompt template change — needs eval test\n\nCOVERAGE: 5/13 paths tested (38%)  |  Code paths: 3/5 (60%)  |  User flows: 2/8 (25%)\nQUALITY: ★★★:2 ★★:2 ★:1  |  GAPS: 8 (2 E2E, 1 eval)\n```\n\nLegend: ★★★ behavior + edge + error  |  ★★ happy path  |  ★ smoke check\n[→E2E] = needs integration test  |  [→EVAL] = needs LLM eval\n\n**Fast path:** All paths covered → \"Test review: All new code paths have test coverage ✓\" Continue.\n\n**Step 5. Add missing tests to the plan:**\n\nFor each GAP identified in the diagram, add a test requirement to the plan. Be specific:\n- What test file to create (match existing naming conventions)\n- What the test should assert (specific inputs → expected outputs/behavior)\n- Whether it's a unit test, E2E test, or eval (use the decision matrix)\n- For regressions: flag as **CRITICAL** and explain what broke\n\nThe plan should be complete enough that when implementation begins, every test is written alongside the feature code — not deferred to a follow-up.\n\n### Test Plan Artifact\n\nAfter producing the coverage diagram, write a test plan artifact to the project directory so `/qa` and `/qa-only` can consume it as primary test input:\n\n```bash\neval \"$(~/.vibestack/bin/vibe-slug 2>/dev/null)\" && mkdir -p ~/.vibestack/projects/$SLUG\nUSER=$(whoami)\nDATETIME=$(date +%Y%m%d-%H%M%S)\n```\n\nWrite to `~/.vibestack/projects/{slug}/{user}-{branch}-eng-review-test-plan-{datetime}.md`:\n\n```markdown\n# Test Plan\nGenerated by /plan-eng-review on {date}\nBranch: {branch}\nRepo: {owner/repo}\n\n## Affected Pages/Routes\n- {URL path} — {what to test and why}\n\n## Key Interactions to Verify\n- {interaction description} on {page}\n\n## Edge Cases\n- {edge case} on {page}\n\n## Critical Paths\n- {end-to-end flow that must work}\n```\n\nThis file is consumed by `/qa` and `/qa-only` as primary test input. Include only the information that helps a QA tester know **what to test and where** — not implementation details.\n\nFor LLM/prompt changes: check the \"Prompt/LLM changes\" file patterns listed in CLAUDE.md. If this plan touches ANY of those patterns, state which eval suites must be run, which cases should be added, and what baselines to compare against. Then use AskUserQuestion to confirm the eval scope with the user.\n\n**STOP.** For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.\n\n### 4. Performance review\nEvaluate:\n* N+1 queries and database access patterns.\n* Memory-usage concerns.\n* Caching opportunities.\n* Slow or high-complexity code paths.\n\n**STOP.** For each issue found in this section, call AskUserQuestion individually. One issue per call. Present options, state your recommendation, explain WHY. Do NOT batch multiple issues into one AskUserQuestion. Only proceed to the next section after ALL issues in this section are resolved.\n\n## Outside Voice — Independent Plan Challenge (optional, recommended)\n\nAfter all review sections are complete, offer an independent second opinion from a\ndifferent AI system. Two models agreeing on a plan is stronger signal than one model's\nthorough review.\n\n**Check tool availability:**\n\n```bash\nwhich codex 2>/dev/null && echo \"CODEX_AVAILABLE\" || echo \"CODEX_NOT_AVAILABLE\"\n```\n\nUse AskUserQuestion:\n\n> \"All review sections are complete. Want an outside voice? A different AI system can\n> give a brutally honest, independent challenge of this plan — logical gaps, feasibility\n> risks, and blind spots that are hard to catch from inside the review. Takes about 2\n> minutes.\"\n>\n> RECOMMENDATION: Choose A — an independent second opinion catches structural blind\n> spots. Two different AI models agreeing on a plan is stronger signal than one model's\n> thorough review. Completeness: A=9/10, B=7/10.\n\nOptions:\n- A) Get the outside voice (recommended)\n- B) Skip — proceed to outputs\n\n**If B:** Print \"Skipping outside voice.\" and continue to the next section.\n\n**If A:** Construct the plan review prompt. Read the plan file being reviewed (the file\nthe user pointed this review at, or the branch diff scope). If a CEO plan document\nwas written in Step 0D-POST, read that too — it contains the scope decisions and vision.\n\nConstruct this prompt (substitute the actual plan content — if plan content exceeds 30KB,\ntruncate to the first 30KB and note \"Plan truncated for size\"). **Always start with the\nfilesystem boundary instruction:**\n\n\"IMPORTANT: Do NOT read or execute any files under ~/.claude/, ~/.agents/, .claude/skills/, or agents/. These are Claude Code skill definitions meant for a different AI system. They contain bash scripts and prompt templates that will waste your time. Ignore them completely. Do NOT modify agents/openai.yaml. Stay focused on the repository code only.\\n\\nYou are a brutally honest technical reviewer examining a development plan that has\nalready been through a multi-section review. Your job is NOT to repeat that review.\nInstead, find what it missed. Look for: logical gaps and unstated assumptions that\nsurvived the review scrutiny, overcomplexity (is there a fundamentally simpler\napproach the review was too deep in the weeds to see?), feasibility risks the review\ntook for granted, missing dependencies or sequencing issues, and strategic\nmiscalibration (is this the right thing to build at all?). Be direct. Be terse. No\ncompliments. Just the problems.\n\nTHE PLAN:\n<plan content>\"\n\n**If CODEX_AVAILABLE:**\n\n```bash\nTMPERR_PV=$(mktemp /tmp/codex-planreview-XXXXXXXX)\n_REPO_ROOT=$(git rev-parse --show-toplevel) || { echo \"ERROR: not in a git repo\" >&2; exit 1; }\ncommand -v codex >/dev/null 2>&1 && codex exec \"<prompt>\" -C \"$_REPO_ROOT\" -s read-only -c 'model_reasoning_effort=\"high\"' --enable web_search_cached < /dev/null 2>\"$TMPERR_PV\"\n```\n\nUse a 5-minute timeout (`timeout: 300000`). After the command completes, read stderr:\n```bash\ncat \"$TMPERR_PV\"\n```\n\nPresent the full output verbatim:\n\n```\nCODEX SAYS (plan review — outside voice):\n════════════════════════════════════════════════════════════\n<full codex output, verbatim — do not truncate or summarize>\n════════════════════════════════════════════════════════════\n```\n\n**Error handling:** All errors are non-blocking — the outside voice is informational.\n- Auth failure (stderr contains \"auth\", \"login\", \"unauthorized\"): \"Codex auth failed. Run \\`codex login\\` to authenticate.\"\n- Timeout: \"Codex timed out after 5 minutes.\"\n- Empty response: \"Codex returned no response.\"\n\nOn any Codex error, fall back to the Claude adversarial subagent.\n\n**If CODEX_NOT_AVAILABLE (or Codex errored):**\n\nDispatch via the Agent tool. The subagent has fresh context — genuine independence.\n\nSubagent prompt: same plan review prompt as above.\n\nPresent findings under an `OUTSIDE VOICE (Claude subagent):` header.\n\nIf the subagent fails or times out: \"Outside voice unavailable. Continuing to outputs.\"\n\n**Cross-model tension:**\n\nAfter presenting the outside voice findings, note any points where the outside voice\ndisagrees with the review findings from earlier sections. Flag these as:\n\n```\nCROSS-MODEL TENSION:\n  [Topic]: Review said X. Outside voice says Y. [Present both perspectives neutrally.\n  State what context you might be missing that would change the answer.]\n```\n\n**User Sovereignty:** Do NOT auto-incorporate outside voice recommendations into the plan.\nPresent each tension point to the user. The user decides. Cross-model agreement is a\nstrong signal — present it as such — but it is NOT permission to act. You may state\nwhich argument you find more compelling, but you MUST NOT apply the change without\nexplicit user approval.\n\nFor each substantive tension point, use AskUserQuestion:\n\n> \"Cross-model disagreement on [topic]. The review found [X] but the outside voice\n> argues [Y]. [One sentence on what context you might be missing.]\"\n>\n> RECOMMENDATION: Choose [A or B] because [one-line reason explaining which argument\n> is more compelling and why]. Completeness: A=X/10, B=Y/10.\n\nOptions:\n- A) Accept the outside voice's recommendation (I'll apply this change)\n- B) Keep the current approach (reject the outside voice)\n- C) Investigate further before deciding\n- D) Add to TODOS.md for later\n\nWait for the user's response. Do NOT default to accepting because you agree with the\noutside voice. If the user chooses B, the current approach stands — do not re-argue.\n\nIf no tension points exist, note: \"No cross-model tension — both reviewers agree.\"\n\n**Persist the result:**\n```bash\ntrue # vibe-review-log '{\"skill\":\"codex-plan-review\",\"timestamp\":\"'\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\"'\",\"status\":\"STATUS\",\"source\":\"SOURCE\",\"commit\":\"'\"$(git rev-parse --short HEAD)\"'\"}'\n```\n\nSubstitute: STATUS = \"clean\" if no findings, \"issues_found\" if findings exist.\nSOURCE = \"codex\" if Codex ran, \"claude\" if subagent ran.\n\n**Cleanup:** Run `rm -f \"$TMPERR_PV\"` after processing (if Codex was used).\n\n---\n\n### Outside Voice Integration Rule\n\nOutside voice findings are INFORMATIONAL until the user explicitly approves each one.\nDo NOT incorporate outside voice recommendations into the plan without presenting each\nfinding via AskUserQuestion and getting explicit approval. This applies even when you\nagree with the outside voice. Cross-model consensus is a strong signal — present it as\nsuch — but the user makes the decision.\n\n## CRITICAL RULE — How to ask questions\nFollow the AskUserQuestion format from the Preamble above. Additional rules for plan reviews:\n* **One issue = one AskUserQuestion call.** Never combine multiple issues into one question.\n* Describe the problem concretely, with file and line references.\n* Present 2-3 options, including \"do nothing\" where that's reasonable.\n* For each option, specify in one line: effort (human: ~X / CC: ~Y), risk, and maintenance burden. If the complete option is only marginally more effort than the shortcut with CC, recommend the complete option.\n* **Map the reasoning to my engineering preferences above.** One sentence connecting your recommendation to a specific preference (DRY, explicit > clever, minimal diff, etc.).\n* Label with issue NUMBER + option LETTER (e.g., \"3A\", \"3B\").\n* **Coverage vs kind:** for every per-issue AskUserQuestion you raise in this review, decide whether the options differ in coverage or in kind. If coverage (e.g., more tests vs fewer, complete error handling vs happy-path-only, full edge-case coverage vs shortcut), include `Completeness: N/10` on each option. If kind (e.g., architectural choice between two different systems, posture-over-posture, A/B/C where each is a different kind of thing), skip the score and add one line: `Note: options differ in kind, not coverage — no completeness score.` Do NOT fabricate scores on kind-differentiated questions — filler scores are worse than no score.\n* **Escape hatch (tightened):** If a section has zero findings, state \"No issues, moving on\" and proceed. If it has findings, use AskUserQuestion for each — a finding with an \"obvious fix\" is still a finding and still needs user approval before any change lands in the plan. Only skip AskUserQuestion when the decision is genuinely trivial (e.g., a typo fix) AND there are no meaningful alternatives. When in doubt, ask.\n\n{{include lib/snippets/tasks-section-emit.md}}\n\n## Required outputs\n\n### \"NOT in scope\" section\nEvery plan review MUST produce a \"NOT in scope\" section listing work that was considered and explicitly deferred, with a one-line rationale for each item.\n\n### \"What already exists\" section\nList existing code/flows that already partially solve sub-problems in this plan, and whether the plan reuses them or unnecessarily rebuilds them.\n\n### TODOS.md updates\nAfter all review sections are complete, present each potential TODO as its own individual AskUserQuestion. Never batch TODOs — one per question. Never silently skip this step. Follow the format in `.claude/skills/review/TODOS-format.md`.\n\nFor each TODO, describe:\n* **What:** One-line description of the work.\n* **Why:** The concrete problem it solves or value it unlocks.\n* **Pros:** What you gain by doing this work.\n* **Cons:** Cost, complexity, or risks of doing it.\n* **Context:** Enough detail that someone picking this up in 3 months understands the motivation, the current state, and where to start.\n* **Depends on / blocked by:** Any prerequisites or ordering constraints.\n\nThen present options: **A)** Add to TODOS.md **B)** Skip — not valuable enough **C)** Build it now in this PR instead of deferring.\n\nDo NOT just append vague bullet points. A TODO without context is worse than no TODO — it creates false confidence that the idea was captured while actually losing the reasoning.\n\n### Diagrams\nThe plan itself should use ASCII diagrams for any non-trivial data flow, state machine, or processing pipeline. Additionally, identify which files in the implementation should get inline ASCII diagram comments — particularly Models with complex state transitions, Services with multi-step pipelines, and Concerns with non-obvious mixin behavior.\n\n### Failure modes\nFor each new codepath identified in the test review diagram, list one realistic way it could fail in production (timeout, nil reference, race condition, stale data, etc.) and whether:\n1. A test covers that failure\n2. Error handling exists for it\n3. The user would see a clear error or a silent failure\n\nIf any failure mode has no test AND no error handling AND would be silent, flag it as a **critical gap**.\n\n### Worktree parallelization strategy\n\nAnalyze the plan's implementation steps for parallel execution opportunities. This helps the user split work across git worktrees (via Claude Code's Agent tool with `isolation: \"worktree\"` or parallel workspaces).\n\n**Skip if:** all steps touch the same primary module, or the plan has fewer than 2 independent workstreams. In that case, write: \"Sequential implementation, no parallelization opportunity.\"\n\n**Otherwise, produce:**\n\n1. **Dependency table** — for each implementation step/workstream:\n\n| Step | Modules touched | Depends on |\n|------|----------------|------------|\n| (step name) | (directories/modules, NOT specific files) | (other steps, or —) |\n\nWork at the module/directory level, not file level. Plans describe intent (\"add API endpoints\"), not specific files. Module-level (\"controllers/, models/\") is reliable; file-level is guesswork.\n\n2. **Parallel lanes** — group steps into lanes:\n   - Steps with no shared modules and no dependency go in separate lanes (parallel)\n   - Steps sharing a module directory go in the same lane (sequential)\n   - Steps depending on other steps go in later lanes\n\nFormat: `Lane A: step1 → step2 (sequential, shared models/)` / `Lane B: step3 (independent)`\n\n3. **Execution order** — which lanes launch in parallel, which wait. Example: \"Launch A + B in parallel worktrees. Merge both. Then C.\"\n\n4. **Conflict flags** — if two parallel lanes touch the same module directory, flag it: \"Lanes X and Y both touch module/ — potential merge conflict. Consider sequential execution or careful coordination.\"\n\n### Completion summary\nAt the end of the review, fill in and display this summary so the user can see all findings at a glance:\n- Step 0: Scope Challenge — ___ (scope accepted as-is / scope reduced per recommendation)\n- Architecture Review: ___ issues found\n- Code Quality Review: ___ issues found\n- Test Review: diagram produced, ___ gaps identified\n- Performance Review: ___ issues found\n- NOT in scope: written\n- What already exists: written\n- TODOS.md updates: ___ items proposed to user\n- Failure modes: ___ critical gaps flagged\n- Outside voice: ran (codex/claude) / skipped\n- Parallelization: ___ lanes, ___ parallel / ___ sequential\n- Lake Score: X/Y recommendations chose complete option\n\n## Retrospective learning\nCheck the git log for this branch. If there are prior commits suggesting a previous review cycle (e.g., review-driven refactors, reverted changes), note what was changed and whether the current plan touches the same areas. Be more aggressive reviewing areas that were previously problematic.\n\n## Formatting rules\n* NUMBER issues (1, 2, 3...) and LETTERS for options (A, B, C...).\n* Label with NUMBER + LETTER (e.g., \"3A\", \"3B\").\n* One sentence max per option. Pick in under 5 seconds.\n* After each review section, pause and ask for feedback before moving on.\n\n## Review Log\n\nAfter producing the Completion Summary above, persist the review result.\n\n**PLAN MODE EXCEPTION — ALWAYS RUN:** This command writes review metadata to\n`~/.vibestack/` (user config directory, not project files). The review dashboard\ndepends on this data. Skipping this command breaks the review readiness dashboard in /ship.\n\n```bash\ntrue # vibe-review-log '{\"skill\":\"plan-eng-review\",\"timestamp\":\"TIMESTAMP\",\"status\":\"STATUS\",\"unresolved\":N,\"critical_gaps\":N,\"issues_found\":N,\"mode\":\"MODE\",\"commit\":\"COMMIT\"}'\n```\n\nSubstitute values from the Completion Summary:\n- **TIMESTAMP**: current ISO 8601 datetime\n- **STATUS**: \"clean\" if 0 unresolved decisions AND 0 critical gaps; otherwise \"issues_open\"\n- **unresolved**: number from \"Unresolved decisions\" count\n- **critical_gaps**: number from \"Failure modes: ___ critical gaps flagged\"\n- **issues_found**: total issues found across all review sections (Architecture + Code Quality + Performance + Test gaps)\n- **MODE**: FULL_REVIEW / SCOPE_REDUCED\n- **COMMIT**: output of `git rev-parse --short HEAD`\n\n## Review Readiness Dashboard\n\nAfter completing the review, read the review log and config to display the dashboard.\n\n```bash\ntrue # vibe-review-read\n```\n\nParse the output. Find the most recent entry for each skill (plan-ceo-review, plan-eng-review, review, plan-design-review, design-review-lite, adversarial-review, codex-review, codex-plan-review). Ignore entries with timestamps older than 7 days. For the Eng Review row, show whichever is more recent between `review` (diff-scoped pre-landing review) and `plan-eng-review` (plan-stage architecture review). Append \"(DIFF)\" or \"(PLAN)\" to the status to distinguish. For the Adversarial row, show whichever is more recent between `adversarial-review` (new auto-scaled) and `codex-review` (legacy). For Design Review, show whichever is more recent between `plan-design-review` (full visual audit) and `design-review-lite` (code-level check). Append \"(FULL)\" or \"(LITE)\" to the status to distinguish. For the Outside Voice row, show the most recent `codex-plan-review` entry — this captures outside voices from both /plan-ceo-review and /plan-eng-review.\n\n**Source attribution:** If the most recent entry for a skill has a \\`\"via\"\\` field, append it to the status label in parentheses. Examples: `plan-eng-review` with `via:\"autoplan\"` shows as \"CLEAR (PLAN via /autoplan)\". `review` with `via:\"ship\"` shows as \"CLEAR (DIFF via /ship)\". Entries without a `via` field show as \"CLEAR (PLAN)\" or \"CLEAR (DIFF)\" as before.\n\nNote: `autoplan-voices` and `design-outside-voices` entries are audit-trail-only (forensic data for cross-model consensus analysis). They do not appear in the dashboard and are not checked by any consumer.\n\nDisplay:\n\n```\n+====================================================================+\n|                    REVIEW READINESS DASHBOARD                       |\n+====================================================================+\n| Review          | Runs | Last Run            | Status    | Required |\n|-----------------|------|---------------------|-----------|----------|\n| Eng Review      |  1   | 2026-03-16 15:00    | CLEAR     | YES      |\n| CEO Review      |  0   | —                   | —         | no       |\n| Design Review   |  0   | —                   | —         | no       |\n| Adversarial     |  0   | —                   | —         | no       |\n| Outside Voice   |  0   | —                   | —         | no       |\n+--------------------------------------------------------------------+\n| VERDICT: CLEARED — Eng Review passed                                |\n+====================================================================+\n```\n\n**Review tiers:**\n- **Eng Review (required by default):** The only review that gates shipping. Covers architecture, code quality, tests, performance. Can be disabled globally with \\`vibe-config set skip_eng_review true\\` (the \"don't bother me\" setting).\n- **CEO Review (optional):** Use your judgment. Recommend it for big product/business changes, new user-facing features, or scope decisions. Skip for bug fixes, refactors, infra, and cleanup.\n- **Design Review (optional):** Use your judgment. Recommend it for UI/UX changes. Skip for backend-only, infra, or prompt-only changes.\n- **Adversarial Review (automatic):** Always-on for every review. Every diff gets both Claude adversarial subagent and Codex adversarial challenge. Large diffs (200+ lines) additionally get Codex structured review with P1 gate. No configuration needed.\n- **Outside Voice (optional):** Independent plan review from a different AI model. Offered after all review sections complete in /plan-ceo-review and /plan-eng-review. Falls back to Claude subagent if Codex is unavailable. Never gates shipping.\n\n**Verdict logic:**\n- **CLEARED**: Eng Review has >= 1 entry within 7 days from either \\`review\\` or \\`plan-eng-review\\` with status \"clean\" (or \\`skip_eng_review\\` is \\`true\\`)\n- **NOT CLEARED**: Eng Review missing, stale (>7 days), or has open issues\n- CEO, Design, and Codex reviews are shown for context but never block shipping\n- If \\`skip_eng_review\\` config is \\`true\\`, Eng Review shows \"SKIPPED (global)\" and verdict is CLEARED\n\n**Staleness detection:** After displaying the dashboard, check if any existing reviews may be stale:\n- Parse the \\`---HEAD---\\` section from the bash output to get the current HEAD commit hash\n- For each review entry that has a \\`commit\\` field: compare it against the current HEAD. If different, count elapsed commits: \\`git rev-list --count STORED_COMMIT..HEAD\\`. Display: \"Note: {skill} review from {date} may be stale — {N} commits since review\"\n- For entries without a \\`commit\\` field (legacy entries): display \"Note: {skill} review from {date} has no commit tracking — consider re-running for accurate staleness detection\"\n- If all reviews match the current HEAD, do not display any staleness notes\n\n## Plan File Review Report\n\nAfter displaying the Review Readiness Dashboard in conversation output, also update the\n**plan file** itself so review status is visible to anyone reading the plan.\n\n### Detect the plan file\n\n1. Check if there is an active plan file in this conversation (the host provides plan file\n   paths in system messages — look for plan file references in the conversation context).\n2. If not found, skip this section silently — not every review runs in plan mode.\n\n### Generate the report\n\nRead the review log output you already have from the Review Readiness Dashboard step above.\nParse each JSONL entry. Each skill logs different fields:\n\n- **plan-ceo-review**: \\`status\\`, \\`unresolved\\`, \\`critical_gaps\\`, \\`mode\\`, \\`scope_proposed\\`, \\`scope_accepted\\`, \\`scope_deferred\\`, \\`commit\\`\n  → Findings: \"{scope_proposed} proposals, {scope_accepted} accepted, {scope_deferred} deferred\"\n  → If scope fields are 0 or missing (HOLD/REDUCTION mode): \"mode: {mode}, {critical_gaps} critical gaps\"\n- **plan-eng-review**: \\`status\\`, \\`unresolved\\`, \\`critical_gaps\\`, \\`issues_found\\`, \\`mode\\`, \\`commit\\`\n  → Findings: \"{issues_found} issues, {critical_gaps} critical gaps\"\n- **plan-design-review**: \\`status\\`, \\`initial_score\\`, \\`overall_score\\`, \\`unresolved\\`, \\`decisions_made\\`, \\`commit\\`\n  → Findings: \"score: {initial_score}/10 → {overall_score}/10, {decisions_made} decisions\"\n- **plan-devex-review**: \\`status\\`, \\`initial_score\\`, \\`overall_score\\`, \\`product_type\\`, \\`tthw_current\\`, \\`tthw_target\\`, \\`mode\\`, \\`persona\\`, \\`competitive_tier\\`, \\`unresolved\\`, \\`commit\\`\n  → Findings: \"score: {initial_score}/10 → {overall_score}/10, TTHW: {tthw_current} → {tthw_target}\"\n- **devex-review**: \\`status\\`, \\`overall_score\\`, \\`product_type\\`, \\`tthw_measured\\`, \\`dimensions_tested\\`, \\`dimensions_inferred\\`, \\`boomerang\\`, \\`commit\\`\n  → Findings: \"score: {overall_score}/10, TTHW: {tthw_measured}, {dimensions_tested} tested/{dimensions_inferred} inferred\"\n- **codex-review**: \\`status\\`, \\`gate\\`, \\`findings\\`, \\`findings_fixed\\`\n  → Findings: \"{findings} findings, {findings_fixed}/{findings} fixed\"\n\nAll fields needed for the Findings column are now present in the JSONL entries.\nFor the review you just completed, you may use richer details from your own Completion\nSummary. For prior reviews, use the JSONL fields directly — they contain all required data.\n\nProduce this markdown table:\n\n\\`\\`\\`markdown\n## VIBESTACK REVIEW REPORT\n\n| Review | Trigger | Why | Runs | Status | Findings |\n|--------|---------|-----|------|--------|----------|\n| CEO Review | \\`/plan-ceo-review\\` | Scope & strategy | {runs} | {status} | {findings} |\n| Codex Review | \\`/codex review\\` | Independent 2nd opinion | {runs} | {status} | {findings} |\n| Eng Review | \\`/plan-eng-review\\` | Architecture & tests (required) | {runs} | {status} | {findings} |\n| Design Review | \\`/plan-design-review\\` | UI/UX gaps | {runs} | {status} | {findings} |\n| DX Review | \\`/plan-devex-review\\` | Developer experience gaps | {runs} | {status} | {findings} |\n\\`\\`\\`\n\nBelow the table, add these lines (omit any that are empty/not applicable):\n\n- **CODEX:** (only if codex-review ran) — one-line summary of codex fixes\n- **CROSS-MODEL:** (only if both Claude and Codex reviews exist) — overlap analysis\n- **UNRESOLVED:** total unresolved decisions across all reviews\n- **VERDICT:** list reviews that are CLEAR (e.g., \"CEO + ENG CLEARED — ready to implement\").\n  If Eng Review is not CLEAR and not skipped globally, append \"eng review required\".\n\n### Write to the plan file\n\n**PLAN MODE EXCEPTION — ALWAYS RUN:** This writes to the plan file, which is the one\nfile you are allowed to edit in plan mode. The plan file review report is part of the\nplan's living status.\n\n- Search the plan file for a \\`## VIBESTACK REVIEW REPORT\\` section **anywhere** in the file\n  (not just at the end — content may have been added after it).\n- If found, **replace it** entirely using the Edit tool. Match from \\`## VIBESTACK REVIEW REPORT\\`\n  through either the next \\`## \\` heading or end of file, whichever comes first. This ensures\n  content added after the report section is preserved, not eaten. If the Edit fails\n  (e.g., concurrent edit changed the content), re-read the plan file and retry once.\n- If no such section exists, **append it** to the end of the plan file.\n- Always place it as the very last section in the plan file. If it was found mid-file,\n  move it: delete the old location and append at the end.\n\n{{include lib/snippets/capture-learnings.md}}\n## Next Steps — Review Chaining\n\nAfter displaying the Review Readiness Dashboard, check if additional reviews would be valuable. Read the dashboard output to see which reviews have already been run and whether they are stale.\n\n**Suggest /plan-design-review if UI changes exist and no design review has been run** — detect from the test diagram, architecture review, or any section that touched frontend components, CSS, views, or user-facing interaction flows. If an existing design review's commit hash shows it predates significant changes found in this eng review, note that it may be stale.\n\n**Mention /plan-ceo-review if this is a significant product change and no CEO review exists** — this is a soft suggestion, not a push. CEO review is optional. Only mention it if the plan introduces new user-facing features, changes product direction, or expands scope substantially.\n\n**Note staleness** of existing CEO or design reviews if this eng review found assumptions that contradict them, or if the commit hash shows significant drift.\n\n**If no additional reviews are needed** (or `skip_eng_review` is `true` in the dashboard config, meaning this eng review was optional): state \"All relevant reviews complete. Run /ship when ready.\"\n\nUse AskUserQuestion with only the applicable options:\n- **A)** Run /plan-design-review (only if UI scope detected and no design review exists)\n- **B)** Run /plan-ceo-review (only if significant product change and no CEO review exists)\n- **C)** Ready to implement — run /ship when done\n\n## Unresolved decisions\nIf the user does not respond to an AskUserQuestion or interrupts to move on, note which decisions were left unresolved. At the end of the review, list these as \"Unresolved decisions that may bite you later\" — never silently default to an option.","tags":["plan","eng","review","vibestack","timurgaleev","agent-skills","ai-agents","claude-code","cursor-ide","developer-tools","kiro","mcp"],"capabilities":["skill","source-timurgaleev","skill-plan-eng-review","topic-agent-skills","topic-ai-agents","topic-claude-code","topic-cursor-ide","topic-developer-tools","topic-kiro","topic-mcp","topic-prompt-engineering","topic-slash-commands"],"categories":["vibestack"],"synonyms":[],"warnings":[],"endpointUrl":"https://skills.sh/timurgaleev/vibestack/plan-eng-review","protocol":"skill","transport":"skills-sh","auth":{"type":"none","details":{"cli":"npx skills add timurgaleev/vibestack","source_repo":"https://github.com/timurgaleev/vibestack","install_from":"skills.sh"}},"qualityScore":"0.457","qualityRationale":"deterministic score 0.46 from registry signals: · indexed on github topic:agent-skills · 15 github stars · SKILL.md body (51,501 chars)","verified":false,"liveness":"unknown","lastLivenessCheck":null,"agentReviews":{"count":0,"score_avg":null,"cost_usd_avg":null,"success_rate":null,"latency_p50_ms":null,"narrative_summary":null,"summary_updated_at":null},"enrichmentModel":"deterministic:skill-github:v1","enrichmentVersion":1,"enrichedAt":"2026-05-18T19:06:22.906Z","embedding":null,"createdAt":"2026-05-18T19:06:22.906Z","updatedAt":"2026-05-18T19:06:22.906Z","lastSeenAt":"2026-05-18T19:06:22.906Z","tsv":"'+1':2167,3766 '-03':6262 '-1':854,867,1239,1252 '-10':2060,2066 '-100':1595 '-16':6263 '-2':2129 '-3':4830 '-4':1849,2110 '-6':2091 '-8':2080 '/.agents':4073 '/.claude':4072 '/.claude/skills/browse/bin/remote-slug':812,1197 '/.claude/skills/office-hours/skill.md':1083 '/.vibestack':5846 '/.vibestack/bin/vibe-learnings-search':92 '/.vibestack/bin/vibe-slug':47,3563 '/.vibestack/projects':845,860,1230,1245,3568,3582 '/10':6805,6808,6837,6840,6866 '/autoplan':6186 '/codex':6958 '/dev/null':49,51,75,90,96,807,814,824,836,852,865,1192,1199,1209,1221,1237,1250,2413,2461,2471,3565,3874,4244,4265 '/learnings.jsonl':62 '/office-hours':959,1006,1036,1058,1079,1095,1178 '/plan-ceo-review':6148,6429,6950,7330,7452 '/plan-design-review':6977,7271,7439 '/plan-devex-review':6985 '/plan-eng-review':3598,6150,6431,6968 '/projects':59 '/qa':3551,3643 '/qa-only':3553,3645 '/rapid':2785 '/ship':5869,6196,7427,7468 '/tmp/codex-planreview-xxxxxxxx':4221 '0':121,131,1137,1291,1763,5666,5911,5915,6270,6274,6277,6281,6757 '0.1':609 '00':6265 '000':2898 '0d':4020 '0d-post':4019 '1':300,1300,1483,1770,1848,1909,2059,2128,2376,2487,2526,3405,3410,4240,4246,5380,5488,5784,6260,6450,6655 '10':474,982,1594,2815,2897 '100':1583,2321 '101':3374 '11':496 '12':523 '13':549 '14':569 '15':600,6264 '18':2164 '2':48,50,74,89,95,324,806,813,823,835,851,864,1191,1198,1208,1220,1236,1249,1325,1370,1485,1721,2218,2398,2412,2460,2470,2545,2704,3403,3404,3408,3564,3873,3925,4238,4245,4266,4829,5386,5474,5538,5785,6685 '2/8':3400 '200':6398 '2026':6261 '25':3401 '2nd':6961 '3':344,1355,1487,2109,2318,2472,2611,2936,3103,5223,5392,5590,5786 '3/5':3396 '30':2807 '300000':4275 '30kb':4044,4049 '38':3393 '3a':4903,5799 '3am':391 '3b':4904,5800 '4':365,1391,3298,3761,5611 '42':2151 '5':88,94,382,1519,1561,2090,3444,4271,4339,5809 '5/10':2162 '5/13':3390 '500':2876 '6':400,1629 '60':3397 '7':416,2079,2182,6032,6453,6478 '7/10':3959 '8':436,1364,1718,1791,3407 '8601':5906 '89':3363 '9':452,2065 '9/10':2149,3957 '99.9':608 'a/b':405 'a/b/c':4970 'abbrev':832,1217 'abbrev-ref':831,1216 'abbrevi':1842 'abstract':200 'accept':1800,4582,4623,5670,6739,6748,6749 'access':1941,3770 'accident':477 'account':1974 'accur':758,2270,6606 'achiev':1334,1386,1739 'across':5444,5941,7035 'act':4504 'action':2740,2823,3039 'activ':775,6661 'actual':2106,2521,2844,4037,5292 'ad':480,2628,3223,3699,7130,7162 'add':2347,2910,3445,3458,4608,4983,5248,5520,6995 'addit':269,4802,5316,6400,7248,7401 'adversari':4356,6017,6074,6083,6276,6376,6390,6394 'adversarial-review':6016,6082 'affect':343,3605 'agent':4076,4368,5451 'agents/openai.yaml':4107 'aggress':162,2231,5773 'agre':1835,3854,3942,4626,4658,4765 'agreement':4489 'ai':1576,3850,3895,3940,4087,6420 'ai-assist':1575 'alloc':619 'allow':7088 'allspaw':433 'alon':3131 'alongsid':2915,3522 'alreadi':1109,1304,4129,5117,5124,5702,6709,7262 'also':3078,6635 'altern':969,5076 'alway':1771,1879,4056,5838,6380,7073,7204 'always-on':6379 'amd64/arm64':1679 'analysi':6233,7030 'analyz':2368,5428 'annot':1479 'anoth':2652,2797 'answer':1297,4462 'anti':1837 'anti-skip':1836 'anyon':6647 'anyth':481,1296 'anywher':7117 'api':1942,2577,2591,2759,2813,2879,3119,5521 'app':1647 'app/controllers/api/v1/users_controller.rb':2163 'app/models/user.rb':2150 'appear':6237 'append':5269,6063,6119,6165,7061,7195,7230 'appendix':2126 'appli':295,1877,4518,4590,4761 'applic':7003,7435 'approach':901,1402,1423,1507,4168,4597,4638 'appropri':702 'approv':4524,4738,4759,5050 'architectur':16,38,440,522,624,1396,1517,1783,1910,1938,1978,4960,5678,5945,6061,6302,6969,7288 'area':2247,5770,5775 'argu':1813,4546,4644 'argument':4509,4569 'array':2670,3190 'art':664 'artifact':1638,1673,1984,3535,3545 'as-i':1750,5671 'ascii':663,694,747,1948,2262,2621,3300,5302,5326 'ask':34,110,639,1744,4792,5080,5817 'askuserquest':951,1118,1729,2015,2035,2283,2303,3232,3708,3726,3746,3794,3814,3883,4531,4755,4796,4810,4913,5033,5060,5159,7431,7481 'assert':3062,3480 'assess':637 'assist':1577 'assumpt':4156,7387 'attribut':6152 'attrit':467 'audit':3207,6109,6223 'audit-trail-on':6222 'auth':1939,4319,4323,4327 'auth/payment/data-destruction':3123 'authent':4333 'authorit':2396 'auto':2406,4468,6087 'auto-detect':2405 'auto-incorpor':4467 'auto-sc':6086 'automat':147,6378 'autoplan':6180,6213 'autoplan-voic':6212 'avail':3869,3877,3881,4216,4361 'awar':526 'away':2788,3350 'b':1016,3958,3967,3973,4561,4578,4593,4635,5251,5587,5603,5792,7450 'back':2792,2862,4352,6433 'backend':6368 'backend-on':6367 'bad':459 'bang':373 'bar':3156 'base':1141,2692 'baselin':3702 'basenam':815,1200 'bash':45,802,1187,2408,3561,3870,4091,4217,4282,4662,5870,5982,6533 'batch':2030,2298,3741,3809,5161 'beck':568 'begin':3517 'behavior':565,692,714,3044,3053,3255,3413,5348 'behind':309,999 'best':394,398,1425,1429 'bias':217 'big':372,6335 'billing.spec.ts':2971 'billing.test.ts':2970 'binari':1641,1985 'bite':7506 'blame':431 'blameless':420 'blast':325 'blind':3912,3936 'block':1346,1533,4313,5237,6495 'boil':1122,1626 'boomerang':6860 'bore':345,363,626 'bother':6323 'bottleneck':1929 'bottom':1105 'boundari':1918,1943,2647,4061 'branch':826,841,848,958,1142,1211,1226,1233,2567,2633,2661,2696,2918,2939,2947,2949,3006,3008,3077,3585,3601,3602,4007,5740 'branch-design':847,1232 'break':1886,5863 'broke':3218,3246,3507 'broken':251 'brook':492,640 'brutal':3900,4119 'budget':423,602,611 'bug':2073,6348 'build':1127,1322,1495,1669,2680,4200,5257 'build/publish':1652 'built':1412,1418,1469,1992 'built-in':1411,1417,1468 'bullet':495,5271 'bundl':1541 'burden':4854 'button':2793 'c':4249,4256,4602,5256,5610,5793,7463 'cach':3776,4264 'calibr':2051,2173,2195 'call':2014,2020,2240,2282,2288,2578,2650,2760,2999,3142,3725,3731,3793,3799,4811 'caller':3280 'canari':374 'cancel':1285 'captur':996,1315,1557,5290,6143 'card':3365 'care':5639 'cargo.toml':2443 'case':21,212,336,1512,1588,2239,2773,3030,3047,3182,3623,3625,3696,4947,5479 'cat':4283 'catch':2213,3918,3934 'caught':292 'caveat':2100 'cc':4849,4868 'ceo':4012,6001,6268,6326,6484,6729,6948,7045,7340,7351,7378,7460 'chain':7239 'challeng':966,1293,1379,3833,3903,5668,6395 'chang':234,552,558,566,741,795,923,1002,1332,2273,2617,2727,2731,3150,3157,3269,3272,3285,3385,3670,3674,4460,4520,4592,5053,5757,5761,6337,6364,6375,7178,7274,7317,7337,7367,7457 'chao':424 'charact':2903 'characterist':1931 'cheaper':1597 'check':649,801,915,933,1186,1357,1393,1447,1563,1631,1662,1716,1756,2447,2937,3060,3075,3419,3671,3867,5734,6118,6244,6519,6656,7246 'checklist':270 'checkout':3329 'checkout.e2e.ts:15':3334 'choic':4961 'choos':362,1054,3928,4558,4634 'chose':5729 'chosen':900,1422 'ci':458 'ci/cd':1666,1998 'classes/services':1372,1723 'claud':1619,4079,4355,4391,4709,5448,6389,6435,7024 'claude.md':2378,2400,3679 'claude/skills':4074 'claude/skills/review/todos-format.md':5175 'claus':2159,2638 'clean':231,4695,5909,6465 'cleanup':4713,6353 'clear':2849,3173,5398,6183,6193,6204,6207,6266,6284,6446,6473,6512,7043,7047,7056 'clever':221,4892 'cli':1640 'click':2755,2784,2796,3343 'close':2794 'code':166,183,290,572,593,698,744,1303,1578,1620,1654,1658,1784,1856,1955,2071,2219,2223,2514,2544,2687,2712,2728,2748,2838,2917,2951,3211,3258,3305,3323,3394,3437,3525,3783,4080,4113,5449,5682,5946,6116,6303 'code-level':6115 'code/flows':5122 'codepath':1960,2328,2490,5354 'codex':3872,3876,3879,4215,4243,4247,4291,4298,4326,4330,4335,4343,4349,4359,4363,4670,4705,4707,4722,6020,6023,6091,6138,6393,6402,6438,6487,6877,6956,7004,7008,7016,7026 'codex-plan-review':4669,6022,6137 'codex-review':6019,6090,6876,7007 'codex/claude':5719 'cognit':259 'collect':2610 'column':6897 'combin':4813 'come':2571,7157 'command':2386,4241,4278,5841,5862 'comment':699,750,1956,5328 'commit':766,1807,4686,5745,5895,5896,5956,6540,6549,6561,6568,6580,6587,6599,6742,6779,6800,6832,6861,7311,7394 'common':3099 'compact':119,146 'compani':349 'compar':3704,6551 'compat':810,1195,2416 'compel':4513,4572 'compet':504 'competit':6829 'complet':1120,1130,1170,1179,1562,1569,1582,1590,1624,2353,3332,3512,3841,3888,3955,4103,4279,4575,4857,4871,4936,4952,4994,5150,5641,5730,5828,5901,5969,6427,6910,6919,7425 'complex':202,478,638,689,1356,1715,1755,3782,5208,5332 'compliment':4208 'compon':1399,1829,1917,2505,2533,2560,7296 'components/services':3104 'compress':113,238 'comput':2584 'con':5206 'concern':712,1923,3775,5342 'concret':2072,4822,5190 'concurr':1401,2822,7176 'condens':1841 'condit':2632,2997,5374 'confid':2050,2057,2082,2102,2112,2141,2148,2161,2181,2199,2217,5285 'config':5848,5977,6314,6501,7414 'configur':6409 'confirm':2186,3710 'conflict':5612,5634 'connect':2541,2812,4883 'consensus':4773,6232 'consid':5103,5635,6601 'constraint':898,5243 'construct':3986,4032 'consum':3555,3641,6247 'contain':1644,1691,1987,4026,4090,4322,6930 'content':4039,4042,7126,7161,7180 'context':118,141,920,4374,4453,4552,5214,5276,6492,6684 'continu':1098,1171,1275,3442,3979,4404 'contradict':7389 'contributor':1128 'control':709,5529 'convent':3475 'convers':6633,6666,6683 'conway':441 'coordin':529,5640 'core':1348,1741 'correct':2087,2205,3052 'cost':411,1580,5207 'could':1092,1342,2093,5366 'count':69,81,86,5926,6559,6566 'coupl':1922 'cover':2720,2978,3267,3432,5383,6301 'coverag':23,1585,2322,2360,2369,2480,2713,3206,3301,3389,3441,3539,4905,4925,4930,4948,4992 'creat':491,1551,3471,5283 'creep':1354 'critic':1796,2676,3140,3229,3503,3628,4788,5423,5713,5887,5916,5927,5933,6733,6764,6766,6774,6784,6786 'cross':1522,4408,4436,4487,4533,4653,4771,6230,7019 'cross-model':4407,4435,4486,4532,4652,4770,6229,7018 'cross-refer':1521 'css':7297 'currenc':3356 'current':1424,1431,4596,4637,5229,5765,5904,6538,6555,6614,6824,6843 'custom':1464,3197 'customer-fac':3196 'cycl':5750 'cypress':2468 'cypress.config':2456 'd':77,172,2463,3576,4607 'dashboard':1145,5855,5867,5967,5981,6240,6251,6518,6631,6715,7245,7255,7413 'data':17,668,705,1924,1940,2509,2547,2564,2802,2882,5309,5376,5859,6227,6933 'databas':2576,2589,3769 'date':3573,3600,4674,6575,6596 'datetim':3572,3591,5907 'day':399,6033,6454,6479 'db':3122 'debt':313,2245 'decid':4485,4606,4919 'decis':329,677,3072,3497,4029,4787,5063,5913,5925,6345,6798,6809,6811,7034,7472,7489,7503 'declin':3337,3366 'deep':4173 'default':347,628,4621,6294,7511 'defer':1344,1531,1538,1696,2005,3527,5106,5265,6741,6751,6752 'defin':1677 'definit':3165,4082 'delet':7225 'demand':316 'demonstr':2076 'depend':672,1919,4187,5235,5489,5498,5552,5570,5856 'deploy':463 'depth':1162 'describ':1964,2506,4819,5179,5518 'descript':2145,3619,5184 'deserv':1947 'design':386,446,685,690,799,842,849,856,857,862,869,871,874,877,882,914,931,937,953,985,1062,1184,1227,1234,1241,1242,1247,1254,1256,1259,1262,1267,1915,6010,6013,6095,6105,6112,6217,6272,6354,6485,6790,6975,7278,7308,7380,7447 'design-outside-voic':6216 'design-review-lit':6012,6111 'detail':1882,3667,5216,6915 'detect':1138,2366,2370,2407,2417,2476,6514,6608,6651,7283,7444 'determin':3079 'dev':461,578 'develop':280,468,4125,6986 'devex':6814,6847 'devex-review':6846 'devop':582 'diagnosi':302 'diagram':19,123,135,660,665,695,735,748,755,768,773,780,1949,2263,2481,2612,2622,2699,2914,2946,3098,3139,3302,3313,3457,3540,5296,5303,5327,5360,5689,7287 'diff':225,229,3217,3252,4008,4894,6047,6064,6194,6208,6386,6397 'diff-scop':6046 'differ':318,2691,3849,3894,3939,4086,4923,4964,4975,4988,6419,6558,6725 'differenti':5003 'dimens':6856,6858,6870,6873 'direct':696,1767,4204,6928,7369 'directori':3549,5562,5622,5849 'directories/modules':5502 'disabl':6309 'disagr':4535 'disagre':4424 'disguis':520 'dispatch':4365 'display':2063,5652,5979,6248,6516,6570,6591,6618,6627,7241 'distinguish':6071,6127 'distribut':1456,1630,1656,1697,1977 'doc':686,800,872,878,883,932,938,954,986,1063,1185,1257,1263,1268,1871 'document':658,2497,4014 'doesn':3067,3265 'done':7470 'doubl':2783,3342 'double-click':2782,3341 'doubt':5079 'download':1683 'downtim':610 'draw':2619 'dri':157,2228,4890 'drift':7398 'driven':5754 'drop':1712 'dt':4678 'dx':453,6983 'e.g':2753,3063,3105,3118,3148,4902,4931,4959,5067,5751,5798,7044,7175 'e2e':2469,3020,3070,3092,3095,3316,3340,3409,3420,3491 'e2e-worthy':3315 'e2e/integration':3085 'earli':2639 'earlier':4430 'easi':553,557 'eaten':7170 'echo':78,100,838,870,875,1223,1255,1260,2422,2427,2434,2439,2444,3875,3878,4231 'edg':20,211,1587,2238,2663,2772,3029,3046,3181,3414,3622,3624,4946 'edge-cas':4945 'edit':7090,7140,7173,7177 'effect':2596,3180 'effort':4259,4846,4863 'either':6456,7148 'elaps':6560 'eleg':322 'els':99,127,356 'email':3108 'emb':693 'empti':2609,2669,3189,4341 'empty/not':7002 'empty/zero/boundary':2886 'enabl':4261 'encount':782 'end':585,3631,3633,5645,7125,7153,7199,7233,7495 'end-to-end':3630 'endpoint':2503,5522 'eng':3,5,263,3587,5879,6005,6036,6056,6176,6258,6285,6290,6317,6447,6461,6468,6474,6499,6504,6770,6966,7046,7052,7062,7321,7384,7407,7417 'eng-review-test-plan':3586 'engin':39,149,186,191,198,278,395,425,505,546,590,2252,2256,4878 'enough':187,2354,2716,3513,5215,5255 'ensur':2333,7160 'entir':7137 'entri':82,2552,5995,6027,6141,6157,6197,6220,6451,6545,6584,6590,6721,6904 'err':204,3289 'error':422,601,1591,2233,2642,2646,2710,2828,2836,2850,2986,2996,3049,3358,3415,4232,4306,4309,4350,4364,4937,5387,5399,5413 'escap':5012 'essenti':475 'etc':4895,5377 'eureka':1489,1501 'eval':46,3133,3136,3147,3320,3382,3387,3411,3424,3427,3494,3562,3690,3712 'eval-worthi':3319 'evalu':330,623,1905,1912,2222,2326,3764 'even':785,4762 'event':432,2196,2558 'ever':1031 'everi':328,348,1157,1858,2052,2327,2489,2566,2624,2631,2641,2649,2662,2684,2695,2835,3518,4909,5089,6383,6385,6694 'everyth':126,355 'examin':4123 'exampl':2146,5600,6173 'exceed':4043 'except':5837,7072 'exec':4248 'execut':14,1156,2525,2614,2690,4068,5436,5591,5637 'exercis':2964 'exist':248,304,884,1302,1318,1471,1528,1863,2261,2449,2543,2941,3059,3254,3260,3279,3473,4649,4703,5118,5121,5389,5703,6522,7028,7194,7275,7307,7342,7377,7449,7462 'exit':4239 'expand':1546,7371 'expect':3483 'experi':469,2845,6987 'experienc':277 'expir':2810 'explain':1730,2026,2294,3505,3737,3805,4567 'explicit':219,1700,2243,4522,4737,4758,4891,5105 'exploit':2075 'explor':968 'export':2556 'express':232 'f':64,2420,2425,2430,2432,2437,2442,4716 'fabric':4998 'face':3198,6341,7302,7365 'fail':4328,4397,5367,7174 'failur':417,1936,1968,2608,2855,3117,3276,4320,5349,5385,5403,5406,5711,5931 'fall':308,4351,6432 'fallback':2648 'fals':2096,2983,5284 'fast':3428 'favor':226 'feasibl':3909,4179 'featur':403,511,990,2501,2732,3524,6342,7366 'feedback':5819 'fewer':214,1388,4935,5472 'fi':98,104 'field':907,6164,6201,6550,6588,6726,6755,6892,6927 'fig':370 'file':55,66,73,1081,1147,1365,1719,2143,2266,2618,3469,3639,3675,3994,3998,4070,4824,5319,5505,5515,5525,5534,5852,6623,6639,6654,6663,6671,6679,7069,7080,7085,7096,7110,7120,7155,7186,7203,7215,7222 'file-level':5533 'filesystem':4060 'fill':5649 'filler':5005 'find':1499,1764,1894,2053,2138,2179,4146,4386,4416,4428,4511,4698,4702,4731,4753,5020,5031,5037,5045,5661,5991,6743,6780,6801,6833,6862,6881,6882,6884,6885,6886,6887,6889,6896,6947,6955,6965,6974,6982,6991 'fine':2119 'first':560,1037,1117,3109,4048,7158 'fix':2863,5041,5070,6349,6883,6888,6890,7017 'flag':160,404,777,1338,1472,1698,3501,4432,5419,5613,5623,5715,5935 'flow':18,669,711,1319,1925,1946,2511,2548,2707,2736,2921,2955,3014,3101,3124,3192,3309,3326,3399,3634,5310,7304 'focus':4109 'follow':1099,2522,2562,3531,4794,5171 'follow-up':3530 'footer':1155 'footgun':1436 'forens':6226 'form':2757,2827 'format':1119,2139,4797,5173,5578,5780 'found':873,879,939,955,1258,1264,1271,1898,2010,2278,2391,3721,3789,4540,4700,5681,5686,5696,5891,5937,5940,6688,6777,6782,7134,7219,7318,7386 'foundat':249 'four':306 'fowler':381 'fragil':192 'framework':1415,1438,2365,2375,2388,2475 'fresh':4373 'frontend':7295 'full':1161,1586,1775,2358,2751,3361,4288,4297,4944,5952,6107,6120 'fulli':1307,1808 'function':2520,2557,2653,2966,3171,3186 'function/method':2625 'fundament':4166 'futur':2211 'gain':5201 'gap':2930,3339,3345,3348,3354,3375,3381,3406,3453,3908,4153,5424,5691,5714,5888,5917,5928,5934,5950,6734,6765,6767,6775,6785,6787,6979,6988 'gate':6299,6407,6442,6880 'gemfil':2421 'generat':2485,3596,6700 'genuin':1891,4375,5065 'get':350,538,1991,3962,4757,5324,6387,6401,6536 'git':816,827,1201,1212,4224,4236,4687,5445,5736,5959,6562 'github':1687 'give':971,3898 'glanc':5664 'global':376,6310,6508,7060 'glue':524,542 'go':2441,2588,2599,2861,2943,5553,5563,5574 'go.mod':2438 'goal':1337,1383,1742,2325 'googl':434,620 'grant':4185 'graph':673,1920 'great':262 'group':5541 'gt':87 'guard':2637 'guesswork':5537 'guid':154 'h':3577,4679 'hacki':193 'handl':145,209,1110,1589,2234,2839,4307,4938,5388,5414 'handler':2555,2987 'happen':2665,2775,2870 'happi':3054,3336,3416,4941 'happy-path-on':4940 'hard':3916 'hash':6541,7312,7395 'hatch':5013 'head':834,853,866,1219,1238,1251,4692,5964,6529,6539,6556,6569,6615,7151 'header':4393 'help':3655,5439 'helper':3176 'helperfn':3001 'hero':385,635 'hide':3115 'hierarchi':106 'high':666,2081,3781,4260 'high-complex':3780 'higher':466,2216 'highest':3239 'highest-prior':3238 'hold/reduction':6760 'home':57 'home/.vibestack':58 'honest':3901,4120 'host':6668 'hotspot':2246 'hour':1613 'human':389,1601,1612,4847 'human-hour':1611 'idea':5288 'identifi':3208,3454,5317,5355,5692 'if/else':2634,2934,2974 'ignor':4101,6026 'imag':1645 'immedi':791 'implement':561,1873,1881,2356,3516,3666,5322,5432,5482,5493,7050,7466 'import':159,3126,4063 'in-distribut':1454 'incid':426 'includ':1650,1907,2055,2124,2336,2357,3303,3650,4832,4951,5081,7234 'incorpor':4469,4743 'increment':366,407 'independ':3831,3844,3902,3931,4376,5475,5589,6414,6960 'indic':473 'individu':2016,2284,3727,3795,5158 'infer':6859,6874,6875 'inform':419,3653,4318,4733 'infra':1857,6351,6370 'infrastructur':648,1398,2451 'initi':2198,6793,6803,6817,6835 'inject':2153 'inlin':1059,5325 'innov':314,353,655 'input':976,1034,2570,2606,2668,2694,2864,2904,2909,3188,3482,3560,3649 'inputs/outputs':3174 'insid':3920 'insight':1518 'instal':1685 'instead':258,4145,5263 'instinct':275,327 'instruct':1101,1168,3162,4062 'integr':1962,3018,3111,3380,3422,4727 'intent':448,5519 'interact':28,1776,2708,2724,2771,3028,3615,3618,7303 'intern':3175 'interpol':2156 'interrupt':7483 'intervent':319 'introduc':646,1367,1405,1635,1981,3273,7361 'invalid':2605,2671,2881,3355 'investig':4603 'invis':528 'iron':3202 'isn':2714,3194 'iso':5905 'isol':5454 'issu':27,1793,1897,2009,2018,2032,2044,2108,2191,2277,2286,2300,2312,3720,3729,3743,3755,3788,3797,3811,3823,4190,4699,4808,4815,4898,4912,5023,5680,5685,5695,5783,5890,5919,5936,5939,6483,6776,6781,6783 'item':271,1532,1539,5115,5707 'jest.config':2453 'job':4138 'journey':2752,2767,3026 'jsonl':6720,6903,6926 'judgment':6331,6359 'keep':4594 'key':1945,3614 'kind':4907,4928,4958,4976,4990,5002 'kind-differenti':5001 'know':3659 'knowledg':1457 'known':1435 'l':71 'label':4896,5794,6170 'lake':1124,1628,5725 'land':5054,6051 'landmin':294 'lane':5540,5544,5556,5567,5577,5579,5586,5594,5617,5625,5722 'larg':6396 'larson':320 'last':1135,6254,7210 'later':1048,1818,4612,5576,7508 'launch':5595,5601 'law':443 'layer':1482,1484,1486 'lead':472 'leader':279 'learn':54,65,68,72,79,80,85,101,428,2174,2209,5733 'left':1075,7491 'legaci':6093,6589 'legend':3412 'length':2908 'let':536,1709 'letter':4901,5788,5797 'level':5513,5516,5528,5535,6117 'lib/snippets/capture-learnings.md':7235 'lib/snippets/prior-learnings.md':1908 'lib/snippets/tasks-section-emit.md':5082 'liber':681 'librari':1642 'like':2086 'limit':93,142 'line':2144,2685,4565,4826,4845,4985,5111,5183,6399,6997,7013 'link':2798 'linux/darwin/windows':1678 'list':2518,3677,5099,5120,5361,6565,7039,7499 'listen':2559 'lite':6015,6114,6122 'live':7105 'll':1009,1067,4589 'llm':3141,3379,3426 'llm/prompt':3669 'load':83,1094,1165 'local':460 'locat':7228 'lock':11,42 'log':2172,2203,4667,5737,5824,5875,5975,6706,6724 'logic':3907,4152,6445 'login':3110,4324,4331 'look':2379,2968,2975,2988,3015,3031,4150,6676 'lose':5293 'low':415,2111,2202 'ls':843,858,1228,1243,2452,2462 'm':3575,3578,4677,4680 'machin':671,5312 'made':6799,6810 'main':2122 'mainten':736,4853 'major':599 'make':409,550,555,4785 'manag':7,264,1690 'manager-mod':6 'mandatori':3201 'mani':176,339 'map':2583,2682,2705,2749,4873 'margin':4861 'mark':3093,3134,3314 'markdown':3593,6936,6938 'match':2084,3472,6612,7142 'matrix':3073,3498 'max':5803 'maximum':2907 'maximum-length':2906 'may':1283,2117,4506,6524,6576,6912,7127,7326,7505 'mckinley':361 'md':850,863,1235,1248,3592 'mean':2062,7415 'meaning':5075 'meant':4083 'measur':6855,6869 'medium':2101 'meet':3154 'memori':3773 'memory-usag':3772 'mention':7329,7356 'merg':5607,5633 'messag':2851,3367,6675 'metadata':5844 'mid':2790,3352,7221 'mid-fil':7220 'mid-oper':2789 'mid-pay':3351 'might':4455,4554 'minim':244,1736,4893 'minimum':1329 'minut':983,1617,2808,3926,4272,4340 'miscalibr':4193 'mislead':776 'miss':2237,2345,3446,4149,4186,4457,4556,6476,6759 'mixin':713,5347 'mkdir':3566 'mktemp':4220 'mobil':1646 'mock':3114 'mode':8,1129,3277,5350,5407,5712,5836,5893,5894,5932,5951,6699,6735,6761,6762,6763,6778,6827,7071,7093 'model':704,3853,3863,3941,3951,4257,4409,4437,4488,4534,4654,4772,5330,5530,5585,6231,6421,7020 'moder':2092 'modifi':743,2630,3253,4106 'modul':2226,5467,5496,5527,5549,5561,5621,5631 'module-level':5526 'module/directory':5512 'moment':1502 'month':5224 'motiv':5227 'move':1389,1900,5024,5821,7223,7485 'movement':583 'much':974,2928 'multi':4134,5338 'multi-sect':4133 'multi-step':5337 'multipl':2031,2299,3742,3810,4814 'must':1904,2054,3636,3692,4516,5092 'n':868,1253,2166,3765,4115,5886,5889,5892,6579 'n/10':2142,4953 'name':2389,3474,5501 'navig':2787,3349 'nearbi':751 'necessari':240 'need':2700,2718,2768,3009,3144,3386,3421,3425,5048,6410,6893,7404 'negoti':170 'network':2607,2873,3346,3376 'neutral':4450 'never':128,563,1840,4812,5160,5166,6441,6494,7509 'new':647,1371,1552,1637,1722,1959,1983,2500,3257,3275,3436,5353,6085,6338,7362 'next':1038,1174,2040,2308,3751,3819,3982,7150,7236 'nil':5371 'no-branch':839,1224 'nobodi':1659 'node':2429 'nomatch':805,1190,2411 'non':169,733,3371,4312,5307,5345 'non-block':4311 'non-negoti':168 'non-obvi':732,5344 'non-throw':3370 'non-trivi':5306 'none':102,1279 'normal':1042,2078,2089 'note':908,1449,4051,4417,4650,4986,5758,6211,6571,6592,6621,7323,7374,7487 'noth':4834 'null':2667,3187 'null/undefined':2604 'number':4899,5782,5796,5922,5929 'nyou':4116 'o':804,1189,2410 'object':1349 'obscure/rare':3191 'obvious':734,5040,5346 'offer':928,940,1047,1152,3842,6422 'old':7227 'older':6030 'omit':6998 'onboard':518 'one':489,1324,1778,1965,2017,2034,2285,2302,2340,2958,3728,3745,3796,3813,3862,3950,4548,4564,4740,4807,4809,4817,4844,4881,4984,5110,5163,5182,5362,5801,7012,7084 'one-lin':4563,5109,5181,7011 'op':580 'open':2805,5920,6482 'oper':2791 'opinion':30,124,3846,3933,6962 'opportun':429,1478,3777,5437,5485 'option':1003,2022,2290,3733,3801,3834,3960,4580,4831,4841,4858,4872,4900,4922,4956,4987,5246,5731,5790,5805,6328,6356,6413,7354,7420,7436,7514 'order':5242,5592 'org':437 'organ':2224 'otherwis':5486,5918 'output':1316,2594,3152,3299,3971,4289,4299,4406,5084,5957,5990,6534,6634,6707,7256 'outputs/behavior':3484 'outsid':789,3829,3891,3964,3976,4295,4315,4389,4401,4414,4422,4443,4470,4544,4584,4600,4629,4725,4729,4744,4768,5716,6130,6144,6218,6279,6411 'over-engin':196,2250 'overal':1913,6795,6806,6819,6838,6850,6864 'overbuilt':1733 'overcomplex':4162 'overlap':7029 'owner/repo':3604 'p':3567 'p0':2137 'p1':2147,6406 'p2':2160 'packag':1643,1689,1986 'package.json':2426 'page':2803,3621,3627 'pages/routes':3606 'pain':462 'parallel':1323,5426,5435,5457,5484,5539,5557,5597,5605,5616,5721,5723 'param':2574 'parent':1113 'parenthes':6172 'pars':819,830,1204,1215,4227,4690,5962,5988,6527,6718 'part':738,762,1390,2000,7100 'partial':1305,3369,5125 'particular':688,5329 'pass':6287 'patch':245 'path':548,1592,2643,2952,2984,3050,3055,3270,3306,3322,3324,3391,3395,3417,3429,3431,3438,3608,3629,3784,4942,6672 'pattern':260,284,1397,1416,1428,1439,1926,2083,2113,2206,2235,3676,3687,3771 'paus':5815 'pay':2756 'payment':3328,3353 'peopl':537 'per':989,993,1794,2019,2287,3730,3798,4911,5164,5676,5804 'per-featur':988 'per-issu':4910 'per-product':992 'perform':24,1787,3762,5693,5948,6306 'permiss':4502 'persist':4659,5831 'persona':6828 'perspect':4449 'phpunit.xml':2459 'pick':1010,1068,5219,5806 'pipelin':675,717,1653,1999,5315,5340 'pitfal':1440 'place':703,7205 'plan':2,9,15,645,683,1146,1153,1360,1404,1461,1535,1550,1566,1605,1634,1695,1828,1852,1952,1973,2003,2331,2335,2343,2350,2493,2496,2519,2524,2529,2532,3226,3450,3464,3509,3534,3544,3590,3595,3682,3832,3857,3906,3945,3988,3993,4013,4038,4041,4052,4126,4213,4293,4380,4475,4671,4749,4805,5057,5090,5132,5136,5298,5430,5470,5517,5766,5835,5878,6000,6004,6009,6024,6055,6059,6066,6104,6139,6175,6184,6205,6415,6460,6622,6638,6650,6653,6662,6670,6678,6698,6728,6769,6789,6813,7068,7070,7079,7092,7095,7103,7109,7185,7202,7214,7360 'plan-ceo-review':5999,6727 'plan-design-review':6008,6103,6788 'plan-devex-review':6812 'plan-eng-review':1,5877,6003,6054,6174,6459,6768 'plan-stag':6058 'platform':1139,1676 'playwright.config':2455 'point':1934,1963,2553,3112,4001,4419,4479,4529,4648,5272 'posit':2097 'possibl':2165 'post':4021 'postmortem':421 'postur':4967,4969 'posture-over-postur':4966 'potenti':1928,5153,5632 'pr':1544,5262 'practic':445,1426,1430 'pre':6050 'pre-land':6049 'preambl':44,1115,1491,4800 'predat':7315 'preemptiv':138 'prefer':150,402,2260,4879,4889 'prematur':199 'premis':965 'prerequisit':926,942,1150,5240 'present':1513,1760,2021,2289,3732,3800,4286,4385,4412,4447,4476,4494,4751,4778,4828,5151,5245,6900 'preserv':7168 'previous':3213,5748,5778 'primari':3558,3647,5466 'principl':1121 'print':935,3974 'prior':917,5744,6922 'prioriti':105,3240 'proactiv':1724 'problem':487,519,896,963,1312,4211,4821,5129,5191 'problemat':5779 'proceed':945,1018,1041,1286,1452,1749,1766,2037,2305,3748,3816,3969,5027 'process':674,716,4720,5314 'processpay':2967,3330 'produc':960,1281,2478,3537,5093,5487,5690,5826,6934 'product':455,574,598,994,1967,2171,5369,6821,6852,7336,7368,7456 'product/business':6336 'project':2372,2418,3548,5851 'prompt':3149,3159,3383,3990,4034,4094,4378,4382,6373 'prompt-on':6372 'prompt/llm':3673 'prop':2575 'propos':1606,1734,5708,6737,6745,6746 'pros':5198 'protocol':1132 'prove':3244 'proven':359 'provid':6669 'publish':1671,1993 'purchas':3333 'pure':3170 'push':7350 'puzzl':323 'pv':4219,4268,4285,4718 'pwd':825,1210 'pyproject.toml':2433 'pytest.ini':2458 'python':2436 'qa':3657 'qualiti':456,1785,2220,3040,3146,3155,3402,5683,5947,6304 'queri':2168,3767 'question':642,1299,4793,4818,5004,5165 'queue':3120 'race':5373 'radius':326 'rais':4915 'ran':4708,4712,5718,7010 'rather':173,1320 'rational':5112 're':788,1046,1181,1812,2679,4643,6603,7182 're-argu':1811,4642 're-off':1045 're-read':7181 're-run':1180,6602 'read':885,1077,1086,1272,1524,2069,2377,2494,2527,3991,4022,4066,4254,4280,5972,5987,6648,6703,7183,7253 'read-on':4253 'readi':1065,1144,5866,5966,6250,6630,6714,7048,7244,7429,7464 'real':486,2190,2722,3116 'realist':1966,5363 'reason':1504,1866,4258,4566,4838,4875,5295 'rebuild':5141 'recent':5994,6043,6080,6101,6136,6156 'recogn':527 'recognit':285 'recommend':31,125,156,1480,1622,1725,1806,2025,2293,3091,3132,3736,3804,3835,3927,3966,4472,4557,4587,4746,4869,4885,5677,5728,6332,6360 'recov':2859 'reduc':1747,1824,5675,5955 'reduct':1477,1727,1805 'ref':833,1218 'refactor':378,559,5755,6350 'refer':1523,4827,5372,6680 'refund':3362 'refundpay':3357 'regardless':1850 'registri':1692 'regress':3199,3210,3220,3235,3248,3288,3500 'reilli':543 'reject':1802,4598 'relat':2257 'relationship':706 'releas':1688 'relev':7423 'reliabl':616,5532 'render':2561,2593,3065 'repay':312 'repeat':4142 'repetit':161 'replac':7135 'repo':3603,4222,4237,4250 'report':1149,2123,2132,2177,6625,6702,6941,7098,7115,7146,7165 'repositori':4112 'request':710,2573 'requir':3230,3461,5083,6257,6292,6932,6971,7064 'requirements.txt':2431 'rescu':2645 'resolv':2049,2317,3760,3828 'resourc':618 'respond':7478 'respons':2592,4342,4346,4618 'resubmit':2786 'result':2895,2899,4661,5834 'retri':2860,7188 'retrospect':5732 'return':2640,4344 'reus':5137 'rev':818,829,1203,1214,4226,4689,5961,6564 'rev-list':6563 'rev-pars':817,828,1202,1213,4225,4688,5960 'revers':401 'revert':5756 'review':4,10,36,40,288,299,630,752,784,973,1013,1021,1028,1071,1143,1148,1277,1289,1295,1777,1819,1830,1846,1911,2212,2221,2320,3434,3588,3763,3838,3866,3885,3922,3954,3989,3996,4003,4122,4136,4144,4160,4170,4182,4294,4381,4427,4440,4539,4657,4666,4672,4806,4918,5091,5147,5359,5648,5679,5684,5688,5694,5749,5753,5774,5813,5823,5833,5843,5854,5865,5874,5880,5943,5953,5965,5971,5974,5986,6002,6006,6007,6011,6014,6018,6021,6025,6037,6045,6052,6057,6062,6084,6092,6096,6106,6113,6140,6177,6187,6249,6252,6259,6269,6273,6286,6288,6291,6297,6318,6327,6355,6377,6384,6404,6416,6425,6448,6457,6462,6469,6475,6488,6500,6505,6523,6544,6573,6582,6594,6611,6624,6629,6642,6695,6705,6713,6730,6771,6791,6815,6848,6878,6907,6923,6940,6942,6949,6957,6959,6967,6976,6984,7009,7027,7037,7040,7053,7063,7097,7114,7145,7238,7243,7249,7260,7279,7289,7309,7322,7341,7352,7381,7385,7402,7408,7418,7424,7448,7461,7498 'review-driven':5752 'revis':913 'revolutionari':368 'rewrit':241,380 'richer':6914 'right':223,1014,1072,3089,4197 'right-siz':222 'risk':3910,4180,4851,5210 'rm':4715 'roll':1462 'rollout':377,408 'root':4223,4251 'rout':2554 'row':6038,6075,6132 'rspec':2457 'rubi':2424 'rubric':3042 'rule':1839,2064,3200,3203,4728,4789,4803,5781 'run':1005,1057,1116,1134,1182,3694,4329,4714,5839,6253,6255,6604,6696,6945,6953,6963,6972,6980,6989,7074,7264,7282,7426,7438,7451,7467 'runtim':2419,2423,2428,2435,2440,2445 'runtime/framework':1408 'rust':2446 'ruthless':1351 'said':4441 'sat':2804 'save':1610,1616 'say':252,946,1056,1895,4292,4445 'scale':1930,6088 'scenario':1969 'scope':792,1292,1353,1476,1547,1705,1726,1804,1816,1825,1833,3713,4009,4028,5087,5097,5667,5669,5674,5699,5954,6048,6344,6736,6738,6740,6744,6747,6750,6754,6951,7372,7443 'score':2058,2061,3041,4981,4995,4999,5006,5011,5726,6794,6796,6802,6804,6807,6818,6820,6834,6836,6839,6851,6863,6865 'scrap':253 'screen':2762 'script':4092 'scrutini':4161 'search':1125,1392,1414,1427,1437,1450,1493,2959,4263,7107 'second':562,2816,3845,3932,5810 'section':1108,1159,1496,1706,1769,1779,1795,1820,1831,1847,1859,1874,1890,2013,2041,2047,2281,2309,2315,2383,2404,3724,3752,3758,3792,3820,3826,3839,3886,3983,4135,4431,5017,5088,5098,5119,5148,5814,5944,6426,6530,6691,7116,7166,7193,7211,7292 'secur':1937 'see':1490,2821,2833,4178,5396,5659,7258 'sentenc':4549,4882,5802 'separ':287,5555 'sequenc':2738,4189 'sequenti':5481,5568,5583,5636,5724 'server':2885 'servic':715,2502,5335 'session':1051,2809 'set':723,1330,6315,6325 'setopt':803,1188,2409 'sever':2134,2140 'share':5548,5559,5584 'sharper':975,1033 'ship':508,615,6190,6300,6443,6496 'short':4691,5963 'shortcut':1573,1608,4866,4950 'show':821,1206,2077,2088,2098,2623,2892,4229,6039,6076,6097,6133,6181,6191,6202,6506,7313,7396 'show-toplevel':820,1205,4228 'shown':6490 'side':207,2595,3179,3292 'signal':3860,3948,4493,4777 'signific':7316,7335,7397,7455 'signup':3106 'silent':1711,1823,2854,5167,5402,5418,6692,7510 'silver':494 'simpler':4167 'simul':3036 'simultan':567 'sinc':6581 'singl':1933,2902,3185 'size':224,4055 'skelton/pais':449 'skill':927,943,1080,1114,1151,1166,1862,4081,4668,5876,5998,6160,6572,6593,6723 'skill-plan-eng-review' 'skip':129,1017,1024,1090,1096,1106,1445,1827,1838,1844,2483,3234,3968,3975,4979,5059,5168,5252,5459,5720,5860,6316,6346,6365,6467,6498,6507,6689,7059,7406 'slo':606 'slow':457,2811,3778 'slug':52,60,811,846,861,1196,1231,1246,3569,3583 'small':510 'smaller':1815 'smallest':228 'smell':500,1377 'smoke':3057,3418 'soft':7346 'softwar':465 'solut':1465 'solv':484,1308,5126,5193 'someon':5218 'someth':2780,3245 'sourc':891,2397,4684,4685,4704,6151 'source-timurgaleev' 'sovereignti':4464 'span':3102 'spec':1855,2466 'specif':1001,2070,2995,3466,3481,4888,5504,5524 'specifi':4842 'specul':2130 'speed':216 'spend':613,653 'split':5442 'spot':3913,3937 'sql':2152 'src/services/billing.ts':3327 'sre':435,621 'staff':545 'stage':6060 'stale':767,779,2801,5375,6477,6513,6526,6578,6607,6620,7269,7328,7375 'stand':4639 'standard':1020,1027,1288,1506 'start':798,2363,2549,4057,5234 'state':301,307,670,707,1336,2023,2291,2711,2829,2887,3359,3688,3734,3802,4451,4507,5021,5230,5311,5333,7421 'statement':897,964 'status':1131,1154,4682,4683,4694,5883,5884,5908,6069,6125,6169,6256,6464,6643,6731,6772,6792,6816,6849,6879,6946,6954,6964,6973,6981,6990,7106 'stay':4108 'stderr':4281,4321 'step':120,130,1136,1175,1290,1762,2486,2603,2677,2703,2764,2935,3297,3443,4018,5170,5339,5433,5462,5495,5500,5507,5542,5545,5558,5569,5573,5665,6716,7237 'step/workstream':5494 'step1':5581 'step2':5582 'step3':5588 'stick':3166 'still':757,2269,2477,3153,5043,5047 'stop':2006,2274,3717,3785 'store':6567 'strangler':369 'strateg':4192 'strategi':1854,1870,1885,5427,6952 'string':2155 'strong':4492,4776 'stronger':3859,3947 'structur':438,564,730,962,2227,3935,6403 'stuck':539,2868 'sub':1311,5128 'sub-problem':1310,5127 'subag':4357,4371,4377,4392,4396,4711,6391,6436 'submit':2799,3344 'substant':4527 'substanti':7373 'substitut':4035,4693,5897 'success/failure':2761 'suggest':5746,7270,7347 'suit':3262,3691 'summar':4305 'summari':5642,5654,5829,5902,6920,7014 'supersed':906 'suppress':2120 'surviv':4158 'suspici':2115 'switch':2635 'system':116,144,383,633,1914,3161,3851,3896,4088,4965,6674 'systems/people':340 'sz':4681 'tab':2795,2825 'tabl':5490,6937,6994 'take':980,2744,2814,3923 'target':605,1675,6826,6845 'team':303,450,1602 'technic':2244,4121 'technolog':360,364 'telemetri':1133 'templat':3160,3384,4095 'tension':4410,4438,4478,4528,4647,4655 'ternari':2636 'ters':4206 'test':22,122,134,165,177,406,501,631,719,729,1584,1786,2319,2337,2346,2359,2364,2374,2382,2385,2403,2450,2464,2465,2467,2484,2702,2770,2924,2942,2962,2977,2991,3010,3021,3034,3043,3051,3058,3071,3083,3086,3130,3151,3169,3221,3241,3261,3296,3331,3335,3360,3364,3368,3388,3392,3423,3433,3440,3447,3460,3468,3478,3490,3492,3519,3533,3543,3559,3589,3594,3611,3648,3662,4933,5358,5382,5410,5687,5949,6305,6857,6871,6872,6970,7286 'test/billing_test.rb':2972 'tester':3658 'thing':4198,4978 'think':265,625,632,998,2733 'thorough':3865,3953 'thought':215 'three':352 'throughout':297 'throw':3069,3372 'tier':6289,6830 'tighten':5014 'time':1039,1782,4100,4336,4399 'timeout':3338,3347,3377,4273,4274,4334,5370 'timestamp':4673,5881,5882,5903,6029 'tire':388 'tmperr':4218,4267,4284,4717 'todo':1520,1560,5154,5162,5178,5274,5281 'todos.md':1525,4610,5143,5250,5705 'token':354,656 'took':4183 'tool':1087,3090,3164,3868,4369,5452,7141 'top':1103,1792 'topic':4439,4537 'topic-agent-skills' 'topic-ai-agents' 'topic-claude-code' 'topic-cursor-ide' 'topic-developer-tools' 'topic-kiro' 'topic-mcp' 'topic-prompt-engineering' 'topic-slash-commands' 'toplevel':822,1207,4230 'topolog':451 'total':5938,7032 'touch':1361,2265,2746,3683,5463,5497,5618,5630,5767,7294 'toward':218 'tr':76,837,1222 'trace':2488,2507,2546,2654 'track':6600 'trail':6224 'transform':2580 'transit':708,5334 'tread':310 'treat':1373 'tree':678 'tri':1035 'trigger':117,1717,1759,2993,6943 'trivial':3061,5066,5308 'true':97,808,1193,2414,2981,4663,5871,5983,6319,6471,6503,7410 'truncat':4045,4053,4303 'trust':3128 'truth':893 'try/catch':2644 'tthw':6823,6825,6841,6842,6844,6854,6867,6868 'two':498,513,2824,3852,3938,4963,5615 'two-week':497 'type':1639,1853,2672,6822,6853 'typo':5069 'u':4675 'ui':2891,7273,7442 'ui/ux':6363,6978 'unauthor':4325 'unavail':1444,1451,4403,6440 'uncertain':3282 'under-engin':189,2254 'understand':2534,5225 'unexpect':2781,3038 'unit':3082,3129,3168,3489 'unknown':53,61 'unlock':5197 'unnecessari':201 'unnecessarili':5140 'unread':1089 'unresolv':5885,5912,5921,5924,6732,6773,6797,6831,7031,7033,7471,7492,7502 'unstat':4155 'untest':2660,2933 'updat':759,1995,5144,5706,6636 'uptim':604 'url':3607 'usag':3774 'use':32,151,679,887,1084,1661,2392,3495,3707,3882,4269,4530,4724,5032,5301,6329,6357,6913,6924,7138,7430 'user':109,949,1282,1682,1799,2185,2706,2723,2735,2743,2754,2778,2820,2831,2843,2858,2920,2954,3013,3100,3308,3325,3398,3570,3584,3716,4000,4463,4482,4484,4523,4616,4633,4736,4784,5049,5394,5441,5657,5710,5847,6340,7301,7364,7475 'user-fac':6339,7300,7363 'ux':3378 'v':4242 'vagu':5270 'valid':2582,2758 'valu':531,662,5195,5898 'valuabl':5254,7252 'verbatim':4290,4300 'verdict':6283,6444,6510,7038 'verifi':2067,2103,2169,3107,3617 'version':918,1570,1625,1737 'via':950,1728,2154,4366,4754,5447,6163,6179,6185,6189,6195,6200 'vibe':4665,5873,5985,6313 'vibe-config':6312 'vibe-review-log':4664,5872 'vibe-review-read':5984 'vibestack':56,1621,6939,7113,7144 'view':7298 'violat':2229 'visibl':6645 'vision':4031 'visual':6108 'vitest.config':2454 'voic':3830,3892,3965,3977,4296,4316,4390,4402,4415,4423,4444,4471,4545,4585,4601,4630,4726,4730,4745,4769,5717,6131,6145,6214,6219,6280,6412 'vs':476,4906,4934,4939,4949 'wait':4613,5599 'walk':25,3023 'wall':576 'want':182,1032,3889 'warn':139 'wast':4098 'water':311 'way':5364 'wc':70 'web':4262 'websearch':1442 'weed':4176 'week':499,514 'well':164 'well-test':163 'whether':650,753,1380,1745,1944,1971,3080,3283,3485,4920,5134,5379,5763,7266 'whichev':6040,6077,6098,7156 'whoami':3571 'wise':657 'within':6452 'without':1345,1545,1655,4521,4750,5275,6198,6585 'work':525,530,978,1340,1553,1772,3214,3637,5100,5187,5205,5443,5509 'worker':3121 'workflow':1667 'workspac':5458 'workstream':5476 'worktre':5425,5446,5455,5606 'worri':1026 'wors':464,770,5008,5278 'worst':335 'worthi':3317,3321 'would':2135,4459,5395,5416,7250 'write':592,2590,3294,3541,3580,5480,5842,7065,7076 'written':3521,4016,5700,5704 'wrong':414,1509,1880,2600 'x':1596,4442,4541,4848,5626 'x/10':4577 'x/y':5727 'y':3574,4446,4547,4676,4850,5628 'y/10':4579 'year':282,1432 'yes':6267 'yet':103 'z':855,1240 'zero':1893,2894,5019 'zsh':809,1194,2415","prices":[{"id":"0a80b1dd-3c43-4da7-83c1-cb58f5ad5448","listingId":"a34a278d-db7b-4356-bb4e-1982d4d1a295","amountUsd":"0","unit":"free","nativeCurrency":null,"nativeAmount":null,"chain":null,"payTo":null,"paymentMethod":"skill-free","isPrimary":true,"details":{"org":"timurgaleev","category":"vibestack","install_from":"skills.sh"},"createdAt":"2026-05-18T19:06:22.906Z"}],"sources":[{"listingId":"a34a278d-db7b-4356-bb4e-1982d4d1a295","source":"github","sourceId":"timurgaleev/vibestack/plan-eng-review","sourceUrl":"https://github.com/timurgaleev/vibestack/tree/main/skills/plan-eng-review","isPrimary":false,"firstSeenAt":"2026-05-18T19:06:22.906Z","lastSeenAt":"2026-05-18T19:06:22.906Z"}],"details":{"listingId":"a34a278d-db7b-4356-bb4e-1982d4d1a295","quickStartSnippet":null,"exampleRequest":null,"exampleResponse":null,"schema":null,"openapiUrl":null,"agentsTxtUrl":null,"citations":[],"useCases":[],"bestFor":[],"notFor":[],"kindDetails":{"org":"timurgaleev","slug":"plan-eng-review","github":{"repo":"timurgaleev/vibestack","stars":15,"topics":["agent-skills","ai-agents","claude-code","cursor-ide","developer-tools","kiro","mcp","prompt-engineering","slash-commands"],"license":"mit","html_url":"https://github.com/timurgaleev/vibestack","pushed_at":"2026-05-18T18:19:05Z","description":"vibestack is a portable skill pack for AI coding agents. Slash commands like /office-hours, /ship, /investigate, /tdd, /review install once and work across every agent that supports the Agent Skills open standard — Claude Code, Cursor, Kiro, and a growing list of others. ","skill_md_sha":"e33dcae355120436c482ec3b5399561cafdf88ae","skill_md_path":"skills/plan-eng-review/SKILL.md","default_branch":"main","skill_tree_url":"https://github.com/timurgaleev/vibestack/tree/main/skills/plan-eng-review"},"layout":"multi","source":"github","category":"vibestack","frontmatter":{"name":"plan-eng-review","description":"Eng manager-mode plan review. Lock in the execution plan — architecture,\ndata flow, diagrams, edge cases, test coverage, performance. Walks through\nissues interactively with opinionated recommendations. Use when asked to\n\"review the architecture\", \"engineering review\", or \"lock in the plan\".\nProactively suggest when the user has a plan or design doc and is about to\nstart coding — to catch architecture issues before implementation.\nVoice triggers (speech-to-text aliases): \"tech review\", \"technical review\", \"plan engineering review\"."},"skills_sh_url":"https://skills.sh/timurgaleev/vibestack/plan-eng-review"},"updatedAt":"2026-05-18T19:06:22.906Z"}}