---
name: side-project-focus-review
description: Evaluate competing side projects by combining live-product dogfooding, source-code inspection, strategic focus scoring, and agent-use discipline. Use when Antoine asks where to focus among side projects, whether to continue/kill a project, or how to compare exploratory projects with active build projects.
---

# Side Project Focus Review

Use this skill when Antoine asks for a direct recommendation on which side project to focus on, especially when there are live products and local source code to inspect.

## Core principle

Do not evaluate only the idea, only the UI, or only the code. Evaluate the project as a bet:

1. User pain and value proposition
2. Live product clarity and trust
3. Source-code maturity and maintenance burden
4. Validation path and distribution difficulty
5. Whether further work is leverage or productive procrastination

For Antoine, be concise, demanding, and willing to call out agent theater.

## Workflow

1. Establish candidates
   - Capture each product URL.
   - Locate local source code by searching likely project folders for domain names, product names, and package files.
   - If source code cannot be found, say so explicitly and evaluate only the live product.

2. Review live products
   - Load each URL in the browser.
   - Check browser console for obvious JS errors.
   - Walk the core user flow, not just the homepage.
   - Use visual review when trust, positioning, or UX quality matters.
   - Note whether the product feels like:
     - a real tool with a loop,
     - a landing-page prototype,
     - a directory/catalog,
     - or a demo without demand proof.

3. Inspect source code
   - Read package metadata for stack/dependencies.
   - Search for key app files, API routes, data/model files, onboarding/session flows, and persistence layer.
   - Search for code smells: TODO, FIXME, console.log, any, eslint-disable, localStorage, dangerouslySetInnerHTML, test/dummy strings, null pricing, fake data.
   - Run lint/build/test commands where available.
   - Count rough codebase size excluding node_modules, .git, .next, dist, build. If `python` is unavailable, use `python3`.
   - Identify whether the codebase is a real product foundation or a prototype held together by static data.

4. Compare strategically
   Score or rank each project on:
   - value proposition clarity
   - user pain intensity
   - specificity of ICP/use case
   - product maturity
   - code maturity
   - distribution difficulty
   - validation speed
   - personal learning value
   - risk type: legal, technical, strategic, market, trust/safety

5. Recommend focus
   - Pick one active build project.
   - Put other projects into validation/backlog unless they have a sharper wedge.
   - Give concrete kill/continue criteria.
   - Name the trap if applicable: meta-agent tinkering, broad marketplace fantasy, overbuilding, research-as-avoidance, or polishing without users.

6. Provide an operating plan
   - Give a 1-4 week plan.
   - Include P0 fixes, trust/safety issues, and instrumentation.
   - Define the next real-world validation test.
   - Suggest only bounded specialist agents with written briefs: QA, safety reviewer, product critic, engineer, research, growth.

## Output format

For a focus recommendation, keep the final answer direct and decision-oriented:

1. Direct recommendation
2. Short evidence summary
3. Per-project assessment
4. Side-by-side comparison
5. Next 1-4 week plan
6. Agent-use coaching: what agents should and should not do next

For Antoine asking “where are we at?” across the portfolio, use a **portfolio status snapshot** instead of forcing a recommendation essay:

- Start from current-truth sources first: factory cockpit `factory-status.json`, Venture Portfolio, current-state notes, build log, telemetry notes, and memory.
- Use concise sections per asset/venture with bullets for: status, what exists/live, current signal, bottleneck, next useful action, and what not to do.
- Preserve the operating model explicitly: primary proof-case, strategic infrastructure, validation candidate, parked probes.
- Call out if a named item is actually part of another initiative rather than a standalone venture, e.g. clipping as Dopamen acquisition/distribution infrastructure unless Antoine says otherwise.
- Avoid Telegram tables; use headings and bullets.

## Pitfalls

- Do not confuse polish with traction.
- Do not let a technically interesting agent/meta project outrank a project with clearer user pain.
- Do not recommend building more before defining the validation test.
- Do not preserve or expose credentials/secrets. Redact them.
- Do not pretend code quality is good if lint/build fails.
- Do not over-index on local code if the live product is untrustworthy or unclear.

## Useful commands/checks

- Search local code for domain/product terms.
- Read `package.json`.
- Run `npm run lint` if present.
- Inspect API routes and data/persistence files.
- Use browser console after loading and after core interactions.
- Use visual browser review for UX/trust/positioning.