eric/project-work
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Project-2 baseline

Browse Source
This commit is contained in:
Eric Bell
2026-10-04 21:19:23 -04:00
parent 0f04889edf
commit 213eb3c403
861 changed files with 1710 additions and 3363322 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
worker-toolkit-potion-polyglot/.claude/skills/brainstorm-product-arcs/SKILL.md
View File

@@ -1,6 +1,6 @@
---
name: brainstorm-product-arcs
description: Invent big, plausible product directions ("arcs") for a source repo and decompose each into a backlog of concrete tasks that can actually be built and verified with no network access. Use when you want task ideas that ladder into a coherent product story instead of one-off commits.
description: Invent big, plausible product directions ("arcs") for a source repo and decompose each into a backlog of concrete tasks that can actually be built and verified without depending on the network. Use when you want task ideas that ladder into a coherent product story instead of one-off commits.
allowed-tools: Read, Glob, Grep, Bash, Write, Edit, WebSearch, WebFetch, Task
---
@@ -24,7 +24,7 @@ Every arc has to pass all three. Most ideas die on lens 3.
1. **Plausible** — obviously something _this_ company would do. The test: is it an expansion of what they already do, or a pivot "into making printers"? Ground it in the real product, not the brand.
2. **Differentiated** — a sharp, concrete delta against both (a) what the product does _today_ and (b) the _workaround_ a user reaches for now (a named competitor or a manual process).
3. **Buildable with no network** — the substance has to be exercisable by a test suite in a sandbox with no internet. This is the gate, and it's the heart of this skill (Step 4).
3. **Buildable without the network** — the substance has to be exercisable by a test suite that never leaves the sandbox. This is the gate, and it's the heart of this skill (Step 4).
## Step 1 — Map the product surface first (go deep; don't guess)
@@ -67,7 +67,7 @@ Name the real external services and link them. They're load-bearing twice over:
## Step 4 — The buildability filter ("simulate the protocol, not the product")
The sandbox that runs a finished task has **no outbound network access** — you can confirm this yourself by running the task under `harbor-run`. So any external service the feature depends on must be faked locally; there's no calling the real API at grade time. The question is never "does it touch the network" — it's whether a _faithful_ local mock is possible.
**Don't invent an arc whose tasks use the internet.** The sandbox that runs a finished task does reach the network — that can't be switched off — but a task must never *depend* on it. Its correctness can't ride on a third party being up, unchanged, and reachable on grading day, and reaching a real service needs credentials and live state that don't exist here anyway. So any external service the feature depends on must be faked locally. The question is never "does it touch the network" — it's whether a _faithful_ local mock is possible.
Grade every feature into one of three buckets: