[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JK5AFA8QZZG9VXSH77P2NF":3,"skill-same:01M6JK5AFA8QZZG9VXSH77P2NF":111},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":74},"01M6JK5AFA8QZZG9VXSH77P2NF","open-the-shop",null,"Doors unlocked, lights flipped, OPEN sign up - scan environment requirements and verify all external service credentials are populated. The most HITL-heavy prep step; the operator personally stocks the cash drawer. Run once before \u002Fsell-slice; also invocable standalone.","steve-piece\u002Fbytheslice","steve-piece","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F190656564?v=4","01M6JK3M1VYSHFKN1PW540DV5H","Steven Light","01M6JK3MDHEWS5WHC4H0RNKTD9",0,"MIT","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"open the shop","open","shop","stock","slice","for","standalone","true","env setup","line","env","requirements","stage","run","scan","up","business","environment","verify","credentials","operator","2026-11-10 10:12:30",false,"---\nname: open-the-shop\ndescription: \"Doors unlocked, lights flipped, OPEN sign up - scan environment requirements and verify all external service credentials are populated. The most HITL-heavy prep step; the operator personally stocks the cash drawer. Run once before \u002Fsell-slice; also invocable standalone.\"\nuser-invocable: true\ntriggers: [\"\u002Fbytheslice:open-the-shop\", \"\u002Fopen-the-shop\", \"stock the line\", \"open for business\", \"doors open\", \"\u002Fbytheslice:setup-environment\", \"\u002Fsetup-environment\", \"env setup\", \"env-setup stage\"]\n---\n\u003C!-- skills\u002Fopen-the-shop\u002FSKILL.md -->\n\u003C!-- Daily-prep skill - the LAST step before \u002Fsell-slice. Pizza-shop framing: doors unlock, lights flip, OPEN sign goes up. Orchestrator-only: dispatches env-scanner, github-secrets-scanner, checklist-generator, and env-verifier to gate the project on a fully populated environment. Mode-detected (standalone vs sequential). Most HITL-heavy prep step - operator personally provides credentials. -->\n\n# Open the Shop - Environment Gate\n\nEnsures all external services are provisioned and every `.env.local` file is fully populated before feature stages or CI gates begin. Running feature work with missing or placeholder keys causes cascading failures that are hard to diagnose; this gate catches them early.\n\n## Mode detection\n\nThis skill runs in one of two modes, auto-detected at startup:\n\n- **Standalone** - no `docs\u002Fplans\u002F00_master_checklist.md` at the project root. Walks env-var setup on any project. Runs end-to-end, exits. No checklist coordination.\n- **Sequential** - master checklist exists with a `## Prep` section. On completion, flip the `[ ] Shop open` row to `[x]` and surface: *\"Shop is open. Foundation prep complete. Run `\u002Fsell-slice` to start serving customers.\"*\n\nHonor an explicit `--standalone` or `--sequential` flag if passed; otherwise auto-detect from disk state.\n\n**Unattended runs.** When `bytheslice.config.json` sets `run.unattended: true` (`\u002Fpizza-party` does), Phases 3 and 4 take the **provider-provisioned path** below instead of the manual checklist, and nothing waits on a human: the operator accepted that risk by launching the run. Every choice made in the operator's place is one line in the order ticket's \"Decisions made without you\" section (`docs\u002Fpizza-party\u002Forder.md`). Without `run.unattended`, the interactive path is unchanged.\n\n## Subagent Roster\n\nEach agent is a **registered plugin agent**: dispatch by type `bytheslice:\u003Cname>` (Agent tool `subagent_type`, or `Workflow` `agentType`), passing only the task inputs as the prompt. The files under `.\u002Fagents\u002F` carry the role prompt plus enforced model\u002Feffort\u002Ftools. Fallback (Cursor, or a host without plugin-agent registration): Read the file and dispatch it per [`loop-workflow-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md) \"Agent shape on the fallback path\": its frontmatter goes first as a header (model tier and effort, the normalized tool allowlist, the read-only line for an agent without write tools, the no-git-writes line), then its body, then the inputs; log one self-check line per dispatch in the run log.\n\n| Phase | Agent file | Model | Effort | Mode |\n|-------|-----------|-------|--------|------|\n| 0 | [agents\u002Fenv-scanner.md](agents\u002Fenv-scanner.md) | haiku | low | readonly |\n| 2 | [agents\u002Fgithub-secrets-scanner.md](agents\u002Fgithub-secrets-scanner.md) | haiku | low | readonly |\n| 3 | [agents\u002Fchecklist-generator.md](agents\u002Fchecklist-generator.md) | haiku | low | readonly |\n| 5 | [agents\u002Fenv-verifier.md](agents\u002Fenv-verifier.md) | haiku | low | readonly |\n\n## Reference Files\n\n| File | Purpose |\n| --- | --- |\n| [references\u002Fknown-services-catalog.md](references\u002Fknown-services-catalog.md) | Maps key prefixes → service + provisioning console URL. checklist-generator reads this. |\n| [references\u002Fenv-checklist-template.md](references\u002Fenv-checklist-template.md) | Structural pattern for the user-facing checklist. |\n| [references\u002Fprovider-provisioning.md](references\u002Fprovider-provisioning.md) | Unattended only: read-only authorization checks per provider, how provider tooling writes `.env.local`, local substitutes, and GitHub secrets from provider output. |\n| [scripts\u002Fmerge-env.js](scripts\u002Fmerge-env.js) | Unattended only: merges provider output into `.env.local`, filling only missing or placeholder keys, printing key names only. |\n\n## When to Use\n\n- `\u002Fsell-slice` reaches a `type: env-setup` stage in the master checklist (auto-dispatch).\n- User runs `\u002Fopen-the-shop` directly as an escape hatch.\n- User says \"env setup\", \"set up environment\", \"populate env vars\", or \"provision services\".\n- After CI\u002FCD scaffold is complete (`final-quality-check`) and before the first feature stage.\n\n## Inputs and Preconditions\n\n- Repository exists with at least one `apps\u002F` or `packages\u002F` directory.\n- `final-quality-check` (Stage 2) has completed: `.github\u002Fworkflows\u002F` exists.\n- Clean git working tree on `main`, OR explicit user OK to proceed dirty.\n\nIf no `.env.example` files are found at all, stop and tell the user - this likely means the apps were not scaffolded yet. Recommend completing Stage 2 first. Under `run.unattended: true`, a scaffolded app with no `.env.example` simply needs no keys: record that, write the pass marker, and complete. A dirty tree or a branch other than `main` is recorded and the run continues.\n\n## Workflow\n\n### Phase 0 - Scan\n\nDispatch `env-scanner`. Receives the workspace root; returns the unique key list per `.env.example`.\n\n### Phase 1 - Service Detection\n\nWait for `env-scanner` output. The `checklist-generator` (Phase 3) handles the catalog cross-reference - no separate detection step needed in this skill.\n\n### Phase 2 - GitHub Secrets Detection\n\nDispatch `github-secrets-scanner` with `env-scanner`'s output. Returns the unique secret name list with workflow references.\n\nThis skill cannot verify GitHub secrets directly (no read access to org secrets); it records the user's verbal confirmation only.\n\n### Phase 3 - Checklist Generation\n\nDispatch `checklist-generator` with both scanner outputs and the path to the known-services catalog. Returns the rendered markdown checklist.\n\nDisplay the checklist to the user in full. Include direct links to provisioning consoles from the catalog.\n\n### Phases 3 and 4 under `run.unattended: true` - Provider-provisioned path\n\nReplaces the checklist display and the wait. Follow [references\u002Fprovider-provisioning.md](references\u002Fprovider-provisioning.md):\n\n1. **Map keys to services.** Dispatch `checklist-generator` as usual; use its `services_detected` grouping, not its markdown.\n2. **Find the authorized provider per service.** Read the order ticket's **Answers** (Host, Database, Auth) for the provider and project each service uses. Confirm each with its read-only check (`vercel whoami`, `netlify status`, `wrangler whoami`, `supabase projects list`, `neonctl me`, `turso auth whoami`, `railway whoami`, `fly auth whoami`, `stripe config --list` with output discarded, and the like) or a connected MCP for it. Never pick a provider the operator has not authorized.\n3. **Let the provider tooling write the values.** Pipe each provider's output (`vercel env pull`, the `supabase` CLI, `netlify env:list --plain`, and the like) into `scripts\u002Fmerge-env.js`, which fills only keys the `.env.example` lists that are missing or placeholder. The agent never prints, logs, reads back or types a secret value; an MCP supplies only public values (a project URL, a publishable key).\n4. **Keys no provider covered** follow the no-provider rule:\n   - **Optional** (the app runs without it): leave it out, record it, and pass it to `env-verifier` as excused.\n   - **Required with a local substitute** (SQLite or a local Postgres for a database, a local session or magic-link-to-console for auth, a console logger for email): use the substitute, write its local values through `merge-env.js`, record it.\n   - **Required with no substitute** (the app truly cannot run without it): mark every slice that needs it deferred in the master checklist (row stays `[ ]`, `**Status:** deferred: needs \u003Cservice> credentials`), record the blocker under the ticket's **Deferred**, excuse its keys, and finish with `status: complete_with_deferrals`. Never `needs_human`.\n5. **Destructive operations on shared resources the operator did not name** (creating or deleting a project, resetting a database, rotating keys) are skipped and recorded, never asked about.\n\nThen go straight to Phase 5.\n\n### Phase 4 - Wait for Confirmation\n\nAfter displaying the checklist, ask the user to confirm when they have completed all steps.\n\n**Always provide a recommended answer in available options** when prompting.\n\n**HITL bubble-up rule (interactive path only):** if the user signals they cannot access a required service (no account, blocked by billing, etc.), set `needs_human: true` with `hitl_category: external_credentials` and surface the specific service and key as `hitl_question`.\n\nWhen the user confirms \"done\", proceed to Phase 5.\n\n### Phase 5 - Verification\n\nDispatch `env-verifier`. Under `run.unattended: true`, also pass `excused_keys`: the keys recorded in the ticket as optional-and-omitted or deferred. The verifier:\n- Confirms a `.env.local` exists alongside every `.env.example`\n- Confirms every key from `.env.example` is present in `.env.local` with a non-empty, non-placeholder value\n- Returns a structured result\n\n**If verification passes (`status: pass`):** proceed to Phase 6 - stage complete.\n\n**If verification fails (`status: fail`):** remove `.claude\u002F.bytheslice-state\u002Fenv-check-passed` if it exists, then display a targeted report (missing files, missing keys, placeholder values per file). Then return to Phase 4 and wait for the user to fix and re-confirm. Loop until `status: pass`.\n\nUnder `run.unattended: true` there is no one to wait for: rerun the provider pass once for the failing keys, then send whatever still fails through the no-provider rule (step 4 above) and verify again. The second verify is final.\n\n### Phase 6 - Closeout\n\n1. After `env-verifier` returns `status: pass`, write the literal `pass\\n` to `.claude\u002F.bytheslice-state\u002Fenv-check-passed` (create the state directory if needed). This local marker records only the successful check. Never write environment values, secret names, credentials, or verifier output into it. Remove an existing marker when a later verification fails so the kitchen does not display a stale pass. Record confirmation that all `.env.local` files pass verification.\n2. Record user's verbal confirmation that GitHub secrets are set (if any were listed in Phase 2). Under `run.unattended: true`, set only the secrets a workflow references, with `gh secret set` fed from the provider tooling through a pipe, never echoed (see the reference's \"GitHub Actions secrets\"). Under ship-once only the app's final PR runs CI, so this can happen any time before that PR; record each secret name set, and each referenced secret with no provider path.\n3. Mark the stage complete in `docs\u002Fplans\u002F00_master_checklist.md`.\n4. Walk the [Completion Checklist](#completion-checklist) below and confirm every box is `[x]`.\n5. Report to the user: which services were set up, which files were verified, and the total key count. Under `run.unattended: true`, add which provider filled each service, every substitute or omission, and every deferral (key names and services only), and append a **Progress** line to the order ticket.\n\n## Completion Checklist\n\nWalk this checklist at the end of every run. The stage is not \"done\" until all items are checked.\n\n- [ ] All `.env.example` files in the repo have been scanned and all keys catalogued\n- [ ] All detected services are represented in the manual checklist displayed to the user\n- [ ] GitHub Secrets section was generated (or confirmed empty if no CI secrets needed)\n- [ ] User confirmed all provisioning steps are complete\n- [ ] `env-verifier` subagent returned `status: pass` with zero `missing_files`, zero `missing_keys_per_file`, and zero `placeholder_keys`\n- [ ] User confirmed GitHub repository secrets are set (or confirmed none are required)\n- [ ] If invoked as a `type: env-setup` stage by `sell-slice`, the master-checklist row is flipped to `Completed`\n\nUnder `run.unattended: true`, the rows \"User confirmed all provisioning steps\" and \"User confirmed GitHub repository secrets\" read instead:\n\n- [ ] Every service was filled by an authorized provider's tooling, a recorded local substitute, a recorded omission (optional), or a recorded deferral, each with its ticket line\n- [ ] No command output, log line, ticket line or report shows a secret value\n- [ ] Referenced GitHub secrets were set through a pipe from provider tooling, or recorded as having no provider path\n- [ ] `env-verifier` returned `status: pass` with every remaining gap listed under `excused_keys`\n\n## Hard Constraints\n\n- **Never read, log, or display actual secret values.** The `env-verifier` only checks existence and placeholder patterns - it never surfaces real values. This skill must not work around that constraint.\n- **The agent never writes a value into `.env.local` itself.** On the interactive path population is the user's manual action. Under `run.unattended: true`, provider tooling writes the values through `scripts\u002Fmerge-env.js`, which fills only missing or placeholder keys and never replaces an operator-set value.\n- **Under `run.unattended: true`, never return `needs_human`.** A required service with no provider becomes a local substitute or a deferral (`status: complete_with_deferrals`).\n- **Never skip the verification loop.** Even if the user says \"I've done everything\", `env-verifier` must run before the stage is marked complete.\n- **Sub-skill contract.** When invoked as a `type: env-setup` stage by `sell-slice`, this skill is the entire stage. After completion, mark the stage `Completed` in `docs\u002Fplans\u002F00_master_checklist.md`.\n- **Subagent prompts live in `.\u002Fagents\u002F*.md`.** This SKILL.md is workflow only - never inline subagent prompts here.\n\n## Sub-agent Return Contract\n\nWhen this skill is invoked as a sub-skill by `sell-slice`, return:\n\n```yaml\nstatus: complete | complete_with_deferrals | failed | needs_human   # never needs_human under run.unattended\nsummary: \u003Cone paragraph describing what services were detected, which files were verified, and the final verification outcome>\ndeferred: []   # unattended only: [{service, keys: [\u003Cnames>], slices: [\"N.M\"], reason}]\nsubstitutes: []   # unattended only: [{service, substitute}]\nartifacts: [docs\u002Fplans\u002F00_master_checklist.md]\nneeds_human: false | true\nhitl_category: null | \"external_credentials\"\nhitl_question: null | \"\u003Cwhich service the user cannot access and why>\"\nhitl_context: null | \"\u003Cwhat triggered this - e.g., user reported no access to Stripe billing>\"\n```\n","\u003C!-- skills\u002Fopen-the-shop\u002FSKILL.md -->\n\u003C!-- Daily-prep skill - the LAST step before \u002Fsell-slice. Pizza-shop framing: doors unlock, lights flip, OPEN sign goes up. Orchestrator-only: dispatches env-scanner, github-secrets-scanner, checklist-generator, and env-verifier to gate the project on a fully populated environment. Mode-detected (standalone vs sequential). Most HITL-heavy prep step - operator personally provides credentials. -->\n\n# Open the Shop - Environment Gate\n\nEnsures all external services are provisioned and every `.env.local` file is fully populated before feature stages or CI gates begin. Running feature work with missing or placeholder keys causes cascading failures that are hard to diagnose; this gate catches them early.\n\n## Mode detection\n\nThis skill runs in one of two modes, auto-detected at startup:\n\n- **Standalone** - no `docs\u002Fplans\u002F00_master_checklist.md` at the project root. Walks env-var setup on any project. Runs end-to-end, exits. No checklist coordination.\n- **Sequential** - master checklist exists with a `## Prep` section. On completion, flip the `[ ] Shop open` row to `[x]` and surface: *\"Shop is open. Foundation prep complete. Run `\u002Fsell-slice` to start serving customers.\"*\n\nHonor an explicit `--standalone` or `--sequential` flag if passed; otherwise auto-detect from disk state.\n\n**Unattended runs.** When `bytheslice.config.json` sets `run.unattended: true` (`\u002Fpizza-party` does), Phases 3 and 4 take the **provider-provisioned path** below instead of the manual checklist, and nothing waits on a human: the operator accepted that risk by launching the run. Every choice made in the operator's place is one line in the order ticket's \"Decisions made without you\" section (`docs\u002Fpizza-party\u002Forder.md`). Without `run.unattended`, the interactive path is unchanged.\n\n## Subagent Roster\n\nEach agent is a **registered plugin agent**: dispatch by type `bytheslice:\u003Cname>` (Agent tool `subagent_type`, or `Workflow` `agentType`), passing only the task inputs as the prompt. The files under `.\u002Fagents\u002F` carry the role prompt plus enforced model\u002Feffort\u002Ftools. Fallback (Cursor, or a host without plugin-agent registration): Read the file and dispatch it per [`loop-workflow-fallback-pattern.md`](..\u002Fcook-pizzas\u002Freferences\u002Floop-workflow-fallback-pattern.md) \"Agent shape on the fallback path\": its frontmatter goes first as a header (model tier and effort, the normalized tool allowlist, the read-only line for an agent without write tools, the no-git-writes line), then its body, then the inputs; log one self-check line per dispatch in the run log.\n\n| Phase | Agent file | Model | Effort | Mode |\n|-------|-----------|-------|--------|------|\n| 0 | [agents\u002Fenv-scanner.md](agents\u002Fenv-scanner.md) | haiku | low | readonly |\n| 2 | [agents\u002Fgithub-secrets-scanner.md](agents\u002Fgithub-secrets-scanner.md) | haiku | low | readonly |\n| 3 | [agents\u002Fchecklist-generator.md](agents\u002Fchecklist-generator.md) | haiku | low | readonly |\n| 5 | [agents\u002Fenv-verifier.md](agents\u002Fenv-verifier.md) | haiku | low | readonly |\n\n## Reference Files\n\n| File | Purpose |\n| --- | --- |\n| [references\u002Fknown-services-catalog.md](references\u002Fknown-services-catalog.md) | Maps key prefixes → service + provisioning console URL. checklist-generator reads this. |\n| [references\u002Fenv-checklist-template.md](references\u002Fenv-checklist-template.md) | Structural pattern for the user-facing checklist. |\n| [references\u002Fprovider-provisioning.md](references\u002Fprovider-provisioning.md) | Unattended only: read-only authorization checks per provider, how provider tooling writes `.env.local`, local substitutes, and GitHub secrets from provider output. |\n| [scripts\u002Fmerge-env.js](scripts\u002Fmerge-env.js) | Unattended only: merges provider output into `.env.local`, filling only missing or placeholder keys, printing key names only. |\n\n## When to Use\n\n- `\u002Fsell-slice` reaches a `type: env-setup` stage in the master checklist (auto-dispatch).\n- User runs `\u002Fopen-the-shop` directly as an escape hatch.\n- User says \"env setup\", \"set up environment\", \"populate env vars\", or \"provision services\".\n- After CI\u002FCD scaffold is complete (`final-quality-check`) and before the first feature stage.\n\n## Inputs and Preconditions\n\n- Repository exists with at least one `apps\u002F` or `packages\u002F` directory.\n- `final-quality-check` (Stage 2) has completed: `.github\u002Fworkflows\u002F` exists.\n- Clean git working tree on `main`, OR explicit user OK to proceed dirty.\n\nIf no `.env.example` files are found at all, stop and tell the user - this likely means the apps were not scaffolded yet. Recommend completing Stage 2 first. Under `run.unattended: true`, a scaffolded app with no `.env.example` simply needs no keys: record that, write the pass marker, and complete. A dirty tree or a branch other than `main` is recorded and the run continues.\n\n## Workflow\n\n### Phase 0 - Scan\n\nDispatch `env-scanner`. Receives the workspace root; returns the unique key list per `.env.example`.\n\n### Phase 1 - Service Detection\n\nWait for `env-scanner` output. The `checklist-generator` (Phase 3) handles the catalog cross-reference - no separate detection step needed in this skill.\n\n### Phase 2 - GitHub Secrets Detection\n\nDispatch `github-secrets-scanner` with `env-scanner`'s output. Returns the unique secret name list with workflow references.\n\nThis skill cannot verify GitHub secrets directly (no read access to org secrets); it records the user's verbal confirmation only.\n\n### Phase 3 - Checklist Generation\n\nDispatch `checklist-generator` with both scanner outputs and the path to the known-services catalog. Returns the rendered markdown checklist.\n\nDisplay the checklist to the user in full. Include direct links to provisioning consoles from the catalog.\n\n### Phases 3 and 4 under `run.unattended: true` - Provider-provisioned path\n\nReplaces the checklist display and the wait. Follow [references\u002Fprovider-provisioning.md](references\u002Fprovider-provisioning.md):\n\n1. **Map keys to services.** Dispatch `checklist-generator` as usual; use its `services_detected` grouping, not its markdown.\n2. **Find the authorized provider per service.** Read the order ticket's **Answers** (Host, Database, Auth) for the provider and project each service uses. Confirm each with its read-only check (`vercel whoami`, `netlify status`, `wrangler whoami`, `supabase projects list`, `neonctl me`, `turso auth whoami`, `railway whoami`, `fly auth whoami`, `stripe config --list` with output discarded, and the like) or a connected MCP for it. Never pick a provider the operator has not authorized.\n3. **Let the provider tooling write the values.** Pipe each provider's output (`vercel env pull`, the `supabase` CLI, `netlify env:list --plain`, and the like) into `scripts\u002Fmerge-env.js`, which fills only keys the `.env.example` lists that are missing or placeholder. The agent never prints, logs, reads back or types a secret value; an MCP supplies only public values (a project URL, a publishable key).\n4. **Keys no provider covered** follow the no-provider rule:\n   - **Optional** (the app runs without it): leave it out, record it, and pass it to `env-verifier` as excused.\n   - **Required with a local substitute** (SQLite or a local Postgres for a database, a local session or magic-link-to-console for auth, a console logger for email): use the substitute, write its local values through `merge-env.js`, record it.\n   - **Required with no substitute** (the app truly cannot run without it): mark every slice that needs it deferred in the master checklist (row stays `[ ]`, `**Status:** deferred: needs \u003Cservice> credentials`), record the blocker under the ticket's **Deferred**, excuse its keys, and finish with `status: complete_with_deferrals`. Never `needs_human`.\n5. **Destructive operations on shared resources the operator did not name** (creating or deleting a project, resetting a database, rotating keys) are skipped and recorded, never asked about.\n\nThen go straight to Phase 5.\n\n### Phase 4 - Wait for Confirmation\n\nAfter displaying the checklist, ask the user to confirm when they have completed all steps.\n\n**Always provide a recommended answer in available options** when prompting.\n\n**HITL bubble-up rule (interactive path only):** if the user signals they cannot access a required service (no account, blocked by billing, etc.), set `needs_human: true` with `hitl_category: external_credentials` and surface the specific service and key as `hitl_question`.\n\nWhen the user confirms \"done\", proceed to Phase 5.\n\n### Phase 5 - Verification\n\nDispatch `env-verifier`. Under `run.unattended: true`, also pass `excused_keys`: the keys recorded in the ticket as optional-and-omitted or deferred. The verifier:\n- Confirms a `.env.local` exists alongside every `.env.example`\n- Confirms every key from `.env.example` is present in `.env.local` with a non-empty, non-placeholder value\n- Returns a structured result\n\n**If verification passes (`status: pass`):** proceed to Phase 6 - stage complete.\n\n**If verification fails (`status: fail`):** remove `.claude\u002F.bytheslice-state\u002Fenv-check-passed` if it exists, then display a targeted report (missing files, missing keys, placeholder values per file). Then return to Phase 4 and wait for the user to fix and re-confirm. Loop until `status: pass`.\n\nUnder `run.unattended: true` there is no one to wait for: rerun the provider pass once for the failing keys, then send whatever still fails through the no-provider rule (step 4 above) and verify again. The second verify is final.\n\n### Phase 6 - Closeout\n\n1. After `env-verifier` returns `status: pass`, write the literal `pass\\n` to `.claude\u002F.bytheslice-state\u002Fenv-check-passed` (create the state directory if needed). This local marker records only the successful check. Never write environment values, secret names, credentials, or verifier output into it. Remove an existing marker when a later verification fails so the kitchen does not display a stale pass. Record confirmation that all `.env.local` files pass verification.\n2. Record user's verbal confirmation that GitHub secrets are set (if any were listed in Phase 2). Under `run.unattended: true`, set only the secrets a workflow references, with `gh secret set` fed from the provider tooling through a pipe, never echoed (see the reference's \"GitHub Actions secrets\"). Under ship-once only the app's final PR runs CI, so this can happen any time before that PR; record each secret name set, and each referenced secret with no provider path.\n3. Mark the stage complete in `docs\u002Fplans\u002F00_master_checklist.md`.\n4. Walk the [Completion Checklist](#completion-checklist) below and confirm every box is `[x]`.\n5. Report to the user: which services were set up, which files were verified, and the total key count. Under `run.unattended: true`, add which provider filled each service, every substitute or omission, and every deferral (key names and services only), and append a **Progress** line to the order ticket.\n\n## Completion Checklist\n\nWalk this checklist at the end of every run. The stage is not \"done\" until all items are checked.\n\n- [ ] All `.env.example` files in the repo have been scanned and all keys catalogued\n- [ ] All detected services are represented in the manual checklist displayed to the user\n- [ ] GitHub Secrets section was generated (or confirmed empty if no CI secrets needed)\n- [ ] User confirmed all provisioning steps are complete\n- [ ] `env-verifier` subagent returned `status: pass` with zero `missing_files`, zero `missing_keys_per_file`, and zero `placeholder_keys`\n- [ ] User confirmed GitHub repository secrets are set (or confirmed none are required)\n- [ ] If invoked as a `type: env-setup` stage by `sell-slice`, the master-checklist row is flipped to `Completed`\n\nUnder `run.unattended: true`, the rows \"User confirmed all provisioning steps\" and \"User confirmed GitHub repository secrets\" read instead:\n\n- [ ] Every service was filled by an authorized provider's tooling, a recorded local substitute, a recorded omission (optional), or a recorded deferral, each with its ticket line\n- [ ] No command output, log line, ticket line or report shows a secret value\n- [ ] Referenced GitHub secrets were set through a pipe from provider tooling, or recorded as having no provider path\n- [ ] `env-verifier` returned `status: pass` with every remaining gap listed under `excused_keys`\n\n## Hard Constraints\n\n- **Never read, log, or display actual secret values.** The `env-verifier` only checks existence and placeholder patterns - it never surfaces real values. This skill must not work around that constraint.\n- **The agent never writes a value into `.env.local` itself.** On the interactive path population is the user's manual action. Under `run.unattended: true`, provider tooling writes the values through `scripts\u002Fmerge-env.js`, which fills only missing or placeholder keys and never replaces an operator-set value.\n- **Under `run.unattended: true`, never return `needs_human`.** A required service with no provider becomes a local substitute or a deferral (`status: complete_with_deferrals`).\n- **Never skip the verification loop.** Even if the user says \"I've done everything\", `env-verifier` must run before the stage is marked complete.\n- **Sub-skill contract.** When invoked as a `type: env-setup` stage by `sell-slice`, this skill is the entire stage. After completion, mark the stage `Completed` in `docs\u002Fplans\u002F00_master_checklist.md`.\n- **Subagent prompts live in `.\u002Fagents\u002F*.md`.** This SKILL.md is workflow only - never inline subagent prompts here.\n\n## Sub-agent Return Contract\n\nWhen this skill is invoked as a sub-skill by `sell-slice`, return:\n\n```yaml\nstatus: complete | complete_with_deferrals | failed | needs_human   # never needs_human under run.unattended\nsummary: \u003Cone paragraph describing what services were detected, which files were verified, and the final verification outcome>\ndeferred: []   # unattended only: [{service, keys: [\u003Cnames>], slices: [\"N.M\"], reason}]\nsubstitutes: []   # unattended only: [{service, substitute}]\nartifacts: [docs\u002Fplans\u002F00_master_checklist.md]\nneeds_human: false | true\nhitl_category: null | \"external_credentials\"\nhitl_question: null | \"\u003Cwhich service the user cannot access and why>\"\nhitl_context: null | \"\u003Cwhat triggered this - e.g., user reported no access to Stripe billing>\"\n```\n",{"name":5,"triggers":45,"description":7,"user-invocable":54},[46,47,48,49,50,51,52,27,53],"\u002Fbytheslice:open-the-shop","\u002Fopen-the-shop","stock the line","open for business","doors open","\u002Fbytheslice:setup-environment","\u002Fsetup-environment","env-setup stage",true,"main","fed8bedadf83cf55669447e6c532d4e20a9aaf65","skills\u002Fopen-the-shop",1,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice","https:\u002F\u002Fgithub.com\u002Fsteve-piece","2026-11-12 16:05:34",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":54},[64,67,70],{"tool":65,"command":66},"npx","npx skills add steve-piece\u002Fbytheslice --skill open-the-shop",{"tool":68,"command":69},"bunx","bunx skills add steve-piece\u002Fbytheslice --skill open-the-shop",{"tool":71,"command":72},"pnpm","pnpm dlx skills add steve-piece\u002Fbytheslice --skill open-the-shop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002FSKILL.md",[75,81,85,89,93,97,101,105],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"agents\u002Fchecklist-generator.md","REFERENCE","参考文档",3545,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Fagents\u002Fchecklist-generator.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"agents\u002Fenv-scanner.md",2495,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Fagents\u002Fenv-scanner.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"agents\u002Fenv-verifier.md",4795,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Fagents\u002Fenv-verifier.md",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"agents\u002Fgithub-secrets-scanner.md",2290,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Fagents\u002Fgithub-secrets-scanner.md",{"path":94,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Fenv-checklist-template.md",3290,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Freferences\u002Fenv-checklist-template.md",{"path":98,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Fknown-services-catalog.md",8566,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Freferences\u002Fknown-services-catalog.md",{"path":102,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fprovider-provisioning.md",9013,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Freferences\u002Fprovider-provisioning.md",{"path":106,"resourceType":107,"resourceTypeDesc":108,"sizeBytes":109,"sourceHtmlUrl":110},"scripts\u002Fmerge-env.js","SCRIPT","脚本",3534,"https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fopen-the-shop\u002Fscripts\u002Fmerge-env.js",[112,141,165,192,220,246],{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":118,"publishedAt":40},"01M6JK6TG7HJ54TN5XYD8N3QE8","special-order","Cook a slice with the customer's specifications on the spot: add new features mid-flight to an existing project. Auto-detects project type and extends the master checklist with new stages.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fspecial-order\u002FSKILL.md",[],[119,120,121,122,123,124,125,126,127,128,129,130,26,131,132,133,134,135,136,137,138,139,140,23],"special order","app","project","auto","bolt","customer","features","master","add","opus","feature","custom","Existing","type","with","high","spot","specifications","about","new","request","extend",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":152,"publishedAt":40},"01M6JK6K6SH4N8Q597D3ABRRMR","setup-shop","Start the oven, check ingredients, prep the shop. Bootstrap a new project or configure ByTheSlice in an existing one. First-time install, system-wide config, or per-project setup.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsetup-shop\u002FSKILL.md",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[21,153,154,155,120,156,121,157,34,20,158,159,160,161,162,128,163,24,164,26,138],"setup shop","setup","SET","monorepo","time","configure","create","config","install","start","new project","system",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":179,"publishedAt":40},"01M6JK6CX6DNV9EE9VH6H3YRD0","set-display-case","Build the display case the pies will sit in, bootstrap your design system: tokens, Tailwind config, design rules, and the operator-only \u002Flibrary preview route. Run once before \u002Fsell-slice; also invocable standalone on any project.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fset-display-case\u002FSKILL.md",[171,176],{"categoryNo":172,"categoryName":173,"taxonomyType":174,"taxonomyTypeDesc":175},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":177,"categoryName":178,"taxonomyType":150,"taxonomyTypeDesc":151},"01JBSEEDCAT000000000000032","设计师",[155,180,181,182,25,121,183,34,184,185,186,187,188,32,160,161,39,189,190,191],"display","case","set display case","Tailwind","init","design","only","preview","route","design-system","library","design system",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":202,"publishedAt":40},"01M6JK629AYG2B1NSSDYQAPWP2","sell-slice","Sell a customer their slice - the high-touch single-slice delivery loop. Execute one slice from your master checklist as an interactive spine (prep gate · recon · build-plan auth · \u002Fgoal · branch) + Workflow A (produce) + library gate + Workflow B (verify-once). Run me repeatedly, one fresh chat per slice. For autonomous whole-pie baking use \u002Fsell-pie.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-slice\u002FSKILL.md",[198,201],{"categoryNo":199,"categoryName":200,"taxonomyType":174,"taxonomyTypeDesc":175},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":177,"categoryName":178,"taxonomyType":150,"taxonomyTypeDesc":151},[203,204,23,205,206,207,208,209,32,126,190,210,211,24,212,213,214,215,134,216,217,218,219],"sell slice","sell","branch","loop","fresh","plan","spine","ship","as","touch","use","interactive","chat","build","checklist","deliver","baking",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":227,"publishedAt":40},"01M6JK5RGMT1ZDVNG9CEHQF61Q","sell-pie","Bake a whole Pie autonomously - the v5 forefront delivery loop. A \u002Floop-driven baker that drives ONE Pie (a coherent chapter, usually 3 to 8 slices) to \"ready for review\" without per-slice prompting; each slice runs the context-separated build→test→verify→fix Workflow, commits + pushes (no PR), and advances; when every slice is [x] it stops at the pie boundary and opens one PR via \u002Fbox-it-up. Refuses flat v4 checklists (points you at \u002Fcook-pizzas --repie). For a continuous-review pie (review=continuous) it runs in high-touch \u002Fsell-slice mode. Opt-in merge-per-slice delivery (delivery.mode, or an explicit autonomous-delivery run instruction) instead gives each slice its own branch, PR and green-CI merge; opt-in ship-once delivery (delivery.mode, set by \u002Fpizza-party) merges each pie into one local ship branch on local gates only and ships one PR at the end. The four blocking HITL categories halt the loop instead of rescheduling (an unattended ship-once run defers the slice instead). Use when the user runs \u002Fsell-pie, says \"sell a pie\", \"bake the pie\", \"run the next pie\", \"loop the pie\", or wants one whole chapter delivered hands-off. For a single careful slice use \u002Fsell-slice; for the whole app end to end use \u002Fpizza-party.","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fsell-pie\u002FSKILL.md",[226],{"categoryNo":199,"categoryName":200,"taxonomyType":174,"taxonomyTypeDesc":175},[228,204,155,229,120,230,205,231,232,233,34,234,235,236,186,237,206,238,239,240,218,32,241,242,210,243,244,245],"sell pie","categories","ready","green","mode","end","fix","ci","local","autonomous","workflow","you","review","at","coherent","context","prompting","commits",{"skillNo":247,"name":248,"nameZh":6,"description":249,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":250,"categories":251,"keywords":256,"publishedAt":40},"01M6JK5GSHAXR9EAVBJBACPVGF","pizza-party","Cater a whole app, start to finish: from a short brief to a finished, deployed app with a URL. One interview up front (AskUserQuestion), then no human stops: \u002Fsetup-shop, \u002Fcreate-menu, \u002Fcook-pizzas, the Prep pie, every pie through \u002Fsell-pie in ship-once delivery (all gates local), one PR that ships the app, a deploy to whatever host the operator has authorized (or an artifact or localhost link), and a run record for comparing runs over time. Every decision a sub-skill would normally ask about is decided, recorded in the order ticket, and the run continues. Use when the user runs \u002Fpizza-party, sets a \u002Fgoal to build an app end to end, or says \"build me this app end to end\", \"from scratch to production\", \"pizza party\", \"bake the whole roadmap\" or \"run all pies\".","https:\u002F\u002Fgithub.com\u002Fsteve-piece\u002Fbytheslice\u002Fblob\u002Fmain\u002Fskills\u002Fpizza-party\u002FSKILL.md",[252,255],{"categoryNo":253,"categoryName":254,"taxonomyType":174,"taxonomyTypeDesc":175},"01JBSEEDCAT000000000000011","运维与部署",{"categoryNo":148,"categoryName":149,"taxonomyType":150,"taxonomyTypeDesc":151},[257,258,120,259,157,233,260,261,34,262,236,237,263,264,265,266,159,267,268,269,270],"pizza party","party","brief","short","ticket","decision","host","roadmap","URL","ask","me","artifact","human","when"]