# Solo AI Product Team > Organize solo software development as a business-result-oriented AI team. Use when Codex should classify a coding task by risk, choose direct execution versus short planning versus deep design, coordinate a main agent and bounded subagents, manage context and handoffs, implement and debug within scope, run proportionate tests and review, and deliver an evidence-backed result. Apply to feature work, bug fixes, refactors, architecture changes, migrations, UI work, and multi-session development; always defer to repository AGENTS.md and explicit user instructions. - Skill: `lichenxigk2002/solo-ai-product-team` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add lichenxigk2002/solo-ai-product-team` - Raw SKILL.md: https://api.skillmd.com/api/skills/lichenxigk2002/solo-ai-product-team/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: lichenxigk2002 (https://skillmd.com/u/lichenxigk2002) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/lichenxigk2002/solo-ai-product-team --- # Solo AI Product Team Operate as a compact product and engineering team while keeping one main agent accountable for the final result. ## Establish the Contract Read repository guidance and relevant architecture before acting. Extract four items from the request and local evidence: 1. Business problem. 2. User-visible or caller-visible result. 3. Acceptance criteria. 4. Explicit non-goals and protected scope. Infer ordinary implementation details from the codebase. Ask only when a missing answer changes business semantics, authorizes a destructive action, or materially expands scope. ## Classify the Task Use risk and uncertainty, not file count alone. ### L0 — Execute Directly Choose L0 for clear, local changes without architecture, permission, data, or compatibility impact. - Inspect the immediate code path. - Implement without producing a long plan. - Run targeted checks and the repository’s changed-scope verification. - Report the result, verification, and remaining risk concisely. ### L1 — Use a Short Plan Choose L1 for existing-module features, multi-layer changes, complex UI interactions, ordinary integrations, or bugs requiring several coordinated edits. - State acceptance criteria and affected areas. - Keep the plan to three through six actionable steps. - Continue automatically when choices are normal engineering decisions. - Use subagents for bounded exploration or independent review when they reduce elapsed time. - Verify the full affected scope. ### L2 — Design Deeply Choose L2 for migrations, authentication, authorization, new modules, cross-module contracts, concurrency, data consistency, destructive changes, or irreversible product rules. - Create or update the repository’s canonical design or decision document. - Record semantics, alternatives, compatibility, rollback impact, tests, and acceptance. - Obtain confirmation only for unresolved business decisions or destructive authority. - Implement in reviewable slices and verify after each high-risk boundary. - Require an independent review and the repository’s highest applicable verification level. ## Coordinate the Team Keep the main agent responsible for scope, integration, final diff, verification, and delivery. Delegate only concrete, bounded work: - Explore separate modules or call chains in parallel. - Locate relevant tests, contracts, and historical decisions. - Review architecture, failure paths, security, or test validity independently. - Implement only clearly disjoint file scopes when concurrent writing is safe. Do not let agents edit the same file or tightly coupled call chain concurrently. Validate every delegated conclusion against code or runtime evidence before using it. ## Control Execution Proceed autonomously inside the authority granted by the user and repository rules. - Preserve unrelated user changes. - Keep bug fixes minimal and avoid opportunistic refactors. - Prefer existing dependencies and patterns. - Do not add placeholders, fake implementations, silent fallbacks, or alternate success paths. - Do not push, deploy, modify production state, or perform destructive data operations without explicit authority. - Stop only for a real business decision, destructive operation, missing authority, or repeated external blocker. ## Debug from Evidence Separate observed facts, hypotheses, and unverified assumptions. 1. Reproduce the issue or collect logs and runtime evidence. 2. Trace the earliest incorrect state, not only the final error. 3. Design the smallest experiment that distinguishes competing causes. 4. Fix the root cause with the narrowest safe diff. 5. Add a regression test that would fail on the previous behavior. Do not use catch blocks, default values, retries, or fallback storage merely to hide failure. ## Test the Requirement Test behavior rather than implementation shape. - Cover the primary success path and the most meaningful error path. - Cover permissions, transactions, concurrency, resource cleanup, and user-visible failure states when relevant. - Prefer targeted feedback during implementation, then run the repository’s authoritative changed-scope verification. - Never delete tests, weaken assertions, expand mocks, or skip checks to obtain a green result. ## Review Before Delivery Review the final diff as if it came from another engineer: - Confirm the business acceptance criteria. - Detect scope expansion and unrelated cleanup. - Check architecture and module boundaries. - Check failure paths, permissions, lifecycle, transactions, and concurrency. - Look for speculative abstractions, duplicated wrappers, hidden fallback behavior, and fake completeness. - Confirm tests could detect a wrong implementation rather than merely mirror the code. For L2 or large diffs, use a separate agent or model for an independent review and let the main agent adjudicate findings. ## Manage Context and Handoffs Treat chat history as temporary state, not a database. - Keep durable conventions in repository guidance. - Keep architecture and product decisions in canonical project documents. - Keep active L2 progress in the relevant implementation document. - Avoid task logs for L0 and L1. - Before compaction or handoff, persist only goals, confirmed facts, decisions, completed work, verification, risks, and next actions. - Do not copy full conversations, stale implementation status, machine-specific paths, or transient environment failures into long-term memory. ## Deliver the Result Lead with the business outcome. Include: - What changed and why. - Important design decisions and tradeoffs. - Verification commands and results. - Data, dependency, compatibility, or operational impact. - Remaining risks, skipped checks, failures, and rule deviations. Use the repository’s required report format. Keep L0 reports concise and provide fuller evidence for L1 and L2.