opportunity-factory

Opportunity Factory

A general-purpose workflow that cycles from need discovery to small deliverables, review, measurement, and learning.

When to Use

"Find needs, review, and build" continuously
Mass-produce mobile apps, Steam games, SaaS, educational materials, internal improvements, etc.
Bounce ideas off a rubber duck and break them down into an actionable queue
Design and operate a repeatable workspace factory rather than one-off answers
Given only a theme, autonomously design the workspace, state management, periodic workflows, and review gates
Continuously improve while monitoring state with 2–3 periodic prompts
/Refine-Product-100 all Improve many targets such as over multiple passes

When Not to Use

For one-off implementation, research, or review, normal handling is fine
Coding conventions that must always be followed should be instructions
If the main purpose is a specific persona or tool restriction, use a custom agent
If it is only deterministic synchronization, transformation, or validation, use a script / hook

Core Idea

The abstract loop is as follows.

discover -> research -> evaluate -> design -> build -> review -> launch/track -> learn

Each loop starts not with "what to build next" but with "which pain or demand to validate."

Workflow

Frame the factory Define the target domain, deliverable type, success metrics, and prohibitions within 5 lines.
Rubber-duck the intent Expose assumptions, whose pain it is, existing alternatives, minimal validation, and failure conditions through questions.
Design the workspace loop If the user provides only a theme, design a self-running loop that includes state files, a dashboard, Top-N/portfolio, candidate deep dives, product maturation after GO, weekly workflow review, and a health reconciler.
Create the queue Split the work into discover|research|evaluate|design|build|review|track|learn .
Produce artifacts Each task leaves behind one evidence artifact. Separate judgment, rationale, and next actions.
Run review gates Check UX, technical, legal/regulatory, distribution, and revenue/outcome metrics according to the domain.
Track outcomes Distinguish measured, estimated, and unverified, and deepen only the hits in the next cycle.

Operating Rules

First fix "whose unmet need and what kind," then create the solution.
Make 1 task granular enough to fit in 1 artifact.
Advisory-only schedules are safe but too slow for a real factory; if the user expects progress, add at least one bounded mutating worker that writes one artifact and updates local state.
When running with multiple workers, separate roles such as discovery/research worker, build/decision worker, and reporter-learner, and limit each run to 1 task / 1 artifact / explicit state update.
For small queues, you may run a single-cycle automation without scheduling commander/worker separately (references/runtime-modes.md ## Single-Cycle Automation)。
Mutating workers need atomic duplicate-run prevention (create-new/O_EXCL or a transactional lease, never check-then-create), a worker-wide singleton lock in addition to per-task locks, and a partial-run recovery path that reconciles artifacts instead of trusting a stale in_progress label; see references/lifecycle-and-health.md ## Lock Scopes.
Run the differentiation gate before full evidence collection and build, not as part of the final review; a light probe is allowed, but a candidate that cannot beat existing substitutes must be rejected or re-angled before it consumes the expensive lanes.
Gates must recompute from raw artifact data, not parse the producer's own summary; require machine-comparable types, externalize threshold-setting labels to durable state, and detect near-duplicate items.
For user-facing artifacts, carry design and actual-render acceptance through the producing lanes, not only the workflow reviewer; generated screenshots or passing builds are not visual acceptance (references/workflow.md -> Rendered-UI Acceptance).
A blocking or required-fix review starts a durable repair -> validate -> independent re-review loop; repairs never self-certify, consume the existing persistence budget, and retain finding-level evidence (references/rubber-duck-review.md).
Maintain a canonical dashboard/status state for future sessions and user status answers; every workflow that changes artifacts, queues, gates, portfolio ranking, blockers, or schedules must update it with backup + stale-write checks.
Add a workflow-review loop as a first-class workflow for self-improving factories; it reviews cadence, queue quality, Top-N replacements, dashboard drift, missing gates, and unsafe autonomy at a slower cadence than workers.
Portfolio factories need a Top-N state with explicit replacement rules; do not grow candidate lists forever, and do not replace an incumbent without comparative evidence and reviewer critique.
Separate reviewer, queue-eligibility, and human-approval gates: once the user approves an autonomy envelope, local/private work inside it may advance on reviewer PASS without repeatedly asking the user.
When a selected task hits an approval boundary, record it as blocked with the exact approval needed, then run or create one safe fallback task instead of stalling the factory.
Do not rely on chat history for factory state; write a README/resume contract that tells future sessions which state, queue, outcome, log, and artifact files to read first.
Keep prototype/build lanes in the same factory when the user wants end-to-end production, but gate source generation on a structured candidate-level continue decision plus an MVP boundary artifact.
End-to-end factories need an explicit post-GO maturation lane to private release-readiness; do not let automation stop at graybox GO or silently cross into public release.
Add a bounded health reconciler for JSON/dashboard/prompt/schedule/lock drift; it may auto-repair reversible local drift but must not change criteria, decisions, approval boundaries, or cadence.
If workflows may edit their own prompts or state, enforce the improvement invariants in a guard outside the editable file set, with hash-bound candidates, a critic receipt, change-rate caps, an audit log, and a halt a human must clear; a rule written only inside an editable file is removed by one apply (references/prompt-self-improvement.md).
If the current host cannot build-verify the target platform, mark generated code as compile-oriented and verification-blocked; never report it as built, running, or tested without a platform verification artifact.
Do not mix metrics without explicitly distinguishing measured, estimated, and hypothetical.
Billing, login, external publication, personal information, and legal risk are boundaries for human approval.
Do not embed workspace-specific paths or secrets in the skill body.

AI-Autonomous Operation

AUTO is the default, and approval is only security-approve . The distinction between hard rules and reference defaults is in §Tunable vs Hard Rules; details are in each reference.

#	Chapter	Outline	Details
A	Approval Policy	2 buckets (`auto` / `security-approve`). The latter is one instance of money generation. AI usage is out of scope for the skill. With Backup-First, reversible is auto.	`references/approval-policy.md`
B	Autonomy Mode	Normal / AUTO default / FULL / ALL, 4 levels. If mode is unspecified in setup Phase 0, propose AUTO + confirm. Secret exposure etc. is out of scope in all modes.	`references/runtime-modes.md` (`ai-autonomous` preset)
C	Fallback Lane	On blocked/stall/idle, auto-dequeue 10 lanes sequentially (1 Portfolio → 2 Prompt review → 3 Advisory Critic → 4 Anti-pattern → 5 Discovery → 6 Small-Bet → 7 Learning → 8 Cleanup → 9 Real-surface RO → 10 Digest). Discovery Floor 5 cycles. Browser writes are deferred.	`references/fallback-lane.md`
D	Genuine Blocker Test	Do not immediately declare a blocker on failed/stall; instead go through a 4-question gate (external signal confirmation / alternative approach N / replan / uncontrollable). HITL only if 4/4 Yes; otherwise go to fallback.	`references/fallback-lane.md`
E	Persistence Profile	Standard / Persistent (default) / Exhaustive. Mapping by task class. Cost/quota is out of scope for the skill (left to the adapter). Workers do not increase approaches on their own; the commander replans.	`references/persistence-profile.md`
F	Cadence + Adapter	worker=hourly / workflow-review=weekly + ad-hoc trigger / digest=daily. Per-hour override possible. Adapter is environment-dependent (Copilot Scheduler / Scout / OpenClaw / Copilot App / GH Actions / Task Scheduler / cron). Push cadence is asked once at setup, default manual.	`references/runtime-modes.md`
G	Goal + Focus Theme	Runs indefinitely; stops only on explicit user instruction. At setup, two-stage agreement on north-star + focus theme (3 months, workspace override possible). Theme apply is a Layer 3 blocking critic gate (hard rule). Candidate completion = Top-N naturally disappears + shipped is explicit.	`references/workspace-setup.md` + `references/rubber-duck-review.md`

Tunable vs Hard Rules

A skill has 2 layers: hard rules (unchangeable) and reference defaults (AI/workspace may improve in actual operation).Hard rules: approval bucket structure (auto/security-approve), backup-first principle, blocker test 4-question gate, critic 3 layers, 5 types subject to layer 3 blocking gate, independent re-review after substantive repair, fallback lane auto-refill, fact of agreement on north-star + focus theme, independence contract. Details and reference default list: references/tunable-defaults.md

Output Modes

Rubber Duck / Factory Plan / Workspace Setup / Self-Designing Workspace Setup / Run Slice / Periodic Runtime / Throughput Setup / Prototype Lane / Review — switch responsibilities by use case. Prototype Lane requires validated candidates only + dummy data + WIP limit + platform-verification.

References

AI-Autonomous foundation: rubber-duck-review.md (Layer 1/2/3 + Layer 3 SSOT) / approval-policy.md / fallback-lane.md / persistence-profile.md / tunable-defaults.md / runtime-modes.md (ai-autonomous preset)
Workflow / Setup: workflow.md / workspace-setup.md / self-designing-factory.md / lifecycle-and-health.md / battle-tested-patterns.md / prompt-self-improvement.md / batch-refinement.md / sqlite-state-store.md
State: dashboard-state.md / assets/templates/dashboard-state.json / assets/templates/factory-state.json / assets/templates/factory-state.sqlite.sql / assets/templates/first-run-queue.json / assets/templates/task.json / assets/templates/artifact.md
Prompts: assets/prompts/commander.md / assets/prompts/worker.md / assets/prompts/reporter-learner.md
Scripts: scripts/validate_factory_skill.py / scripts/init_factory_workspace.py / scripts/init_factory_sqlite.py / scripts/smoke_test_initializers.py
Templates / Examples: assets/templates/factory-plan.md / assets/templates/setup-preflight.md / assets/examples/setup-packets.md

Done Criteria

Primitive choice is still Skill, not prompt/instruction/agent/hook
Domain, artifact type, success metric, and constraints are explicit
Target surfaces, state store, prompt runner, schedule capability, and approval boundaries are explicit
Queue has at least one next executable task
Every task has an artifact contract and review gate
Human approval boundaries are named
Reviewer PASS can advance local/private work inside the approved autonomy envelope; human approval is reserved for boundaries explicitly listed in policy
A canonical status dashboard or equivalent resume contract exists, and status answers use it first
Self-improving factories include a scheduled or manual workflow-review loop
Prompt self-improvements are workspace-local, evidenced by an artifact, reversible, and dashboard-recorded
Self-editing factories enforce those invariants outside the editable file set, and a scheduled job is registered disabled, verified, then enabled with durable state already true
Portfolio factories define Top-N capacity, replacement criteria, and demotion/watchlist/rejected states
End-to-end factories define promotion and post-GO maturation stages through private release-readiness, with WIP/slice/retry caps and independent review
A health reconciler detects state/prompt/schedule drift and repairs only reversible local inconsistencies
Interrupted mutating runs can recover stale locks and partial outputs without self-certifying missing verification evidence
If scheduled progress is expected, at least one safe mutating worker exists; advisory-only automation is called out as intentionally slow
Approval-boundary blockers do not empty the run: the runtime records the blocker and keeps at least one safe fallback lane available
Future sessions can resume from durable state files without reading the original chat transcript
Prototype/source-generation tasks require candidate-level continue state, an MVP boundary artifact, dummy data only, WIP limits, and honest platform-verification status