@fraylabs/possible 0.1.2 → 0.1.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/assets/possible/SKILL.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: possible
|
|
3
|
-
description: Turn an unclear ambition into a concrete, verified outcome through a short guided conversation, then assemble and run the right reviewed Codex skills after confirmation. Use when the user invokes $possible, asks what they should build or
|
|
3
|
+
description: Turn an unclear ambition into a concrete, verified outcome through a short guided conversation, then assemble and run the right reviewed Codex skills after confirmation. Use when the user invokes $possible, asks what they should build, ship, release, or operate, wants help defining an outcome before implementation, or wants a Working Web App, Playable Web Game, Hardware Launch, Software Launch, Open-Source Release, Production Web Release, or Web App Operations outcome coordinated end to end.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Possible
|
|
@@ -91,6 +91,8 @@ When invoked as `$possible resume`, look for `.possible/outcome-brief.md`, `.pos
|
|
|
91
91
|
- If the brief exists but the pack or lock does not, return to recommendation or installation without repeating answered questions.
|
|
92
92
|
- If no Possible state exists, begin with the intake question.
|
|
93
93
|
|
|
94
|
+
For a completed Operate pack, `$possible resume` reads the prior dated receipt, carries unresolved work forward, and runs the next requested cycle. Do not repeat intake or reset the operating history. An Operate pack is not complete when it merely writes a workflow: it must execute the first dated cycle.
|
|
95
|
+
|
|
94
96
|
## Boundaries
|
|
95
97
|
|
|
96
98
|
- Pack confirmation authorizes only the disclosed repo-local skill installation and local artifact work.
|
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
Use this bundled snapshot when the Possible MCP tools are unavailable. Link the recommended pack's public page during the recommendation; disclose its relevant source list and reviewed revisions before installing it.
|
|
4
4
|
|
|
5
|
-
Lanes are browsing labels only: Create is a first complete usable thing, Launch is a compelling public presentation, Release is evidence-backed readiness to ship or distribute, and Operate is a repeatable ongoing workflow. Do not ask the user to choose a lane; select across the complete catalog from the desired finished outputs.
|
|
5
|
+
Lanes are browsing labels only: Create is a first complete usable thing, Launch is a compelling public presentation, Release is evidence-backed readiness to ship or distribute, and Operate is a repeatable ongoing workflow. Do not ask the user to choose a lane; select across the complete catalog from the desired finished outputs.
|
|
6
6
|
|
|
7
7
|
## Hardware Launch
|
|
8
8
|
|
|
@@ -49,13 +49,13 @@ Lane: `launch`
|
|
|
49
49
|
|
|
50
50
|
Public page: `https://possible.sh/packs/software-launch`
|
|
51
51
|
|
|
52
|
-
Use for an existing software
|
|
52
|
+
Use for an existing working software product whose primary flow already exists but needs a coherent release and launch presentation.
|
|
53
53
|
|
|
54
|
-
Outputs:
|
|
54
|
+
Outputs: stabilized product release candidate, launch site, demo film, deployment plan, evidence report.
|
|
55
55
|
|
|
56
56
|
Workstreams:
|
|
57
57
|
|
|
58
|
-
-
|
|
58
|
+
- Product release candidate — `vercel-react-best-practices`; stabilizes the existing release candidate and owns `product/` and its test receipt.
|
|
59
59
|
- Launch site — `frontend-design`; owns `site/` and the launch narrative.
|
|
60
60
|
- Demo film — `remotion-best-practices`; owns `film/` and the rendered preview.
|
|
61
61
|
- Release readiness — `web-design-guidelines`, `deploy-to-vercel`; owns `release/` and the deployment plan.
|
|
@@ -143,13 +143,119 @@ npx skills@1.5.19 add anthropics/skills --skill frontend-design --skill webapp-t
|
|
|
143
143
|
|
|
144
144
|
Never imply player demand, accessibility, compatibility, performance, or production readiness beyond direct evidence. Deployment, publishing, analytics, paid assets, and external distribution remain separate gates.
|
|
145
145
|
|
|
146
|
+
## Web App Operations
|
|
147
|
+
|
|
148
|
+
Slug: `web-app-operations`
|
|
149
|
+
|
|
150
|
+
Lane: `operate`
|
|
151
|
+
|
|
152
|
+
Public page: `https://possible.sh/packs/web-app-operations`
|
|
153
|
+
|
|
154
|
+
Use for an existing live web app that needs a repeatable operating loop for detecting problems, triaging work, maintaining dependencies, and recovering safely.
|
|
155
|
+
|
|
156
|
+
Outputs: executable operations check and dated health baseline, issue intake and prioritized operations queue, dependency and security maintenance loop, incident/change/rollback runbooks, exercised recovery drill, first dated operations receipt.
|
|
157
|
+
|
|
158
|
+
Workstreams:
|
|
159
|
+
|
|
160
|
+
- Reliability loop — `webapp-testing`; owns `operations/checks/`, `operations/receipts/`, and the repository-native operations command.
|
|
161
|
+
- Triage and maintenance — `impediment-prioritization`, `dependabot`, `security-review`; owns the operations queue, maintenance/security evidence, and Dependabot configuration.
|
|
162
|
+
- Safe change and incident response — `devops-rollout-plan`, `incident-postmortem`; owns change, incident, rollback, and postmortem surfaces.
|
|
163
|
+
- Fresh review — `webapp-testing`, `security-review`; verifies the integrated operating loop after its first cycle.
|
|
164
|
+
|
|
165
|
+
Sources:
|
|
166
|
+
|
|
167
|
+
- `anthropics/skills`: `webapp-testing`; reviewed `fa0fa64bdc967915dc8399e803be67759e1e62b8`.
|
|
168
|
+
- `github/awesome-copilot`: `impediment-prioritization`, `dependabot`, `security-review`, `devops-rollout-plan`, `incident-postmortem`; reviewed `26fe2d126bf79aafb38f43344d450b69632200f8`.
|
|
169
|
+
|
|
170
|
+
Install:
|
|
171
|
+
|
|
172
|
+
```bash
|
|
173
|
+
npx skills@1.5.19 add anthropics/skills --skill webapp-testing --agent codex
|
|
174
|
+
npx skills@1.5.19 add github/awesome-copilot --skill impediment-prioritization --skill dependabot --skill security-review --skill devops-rollout-plan --skill incident-postmortem --agent codex
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
Establish the durable workflow and execute its first dated cycle. One health snapshot never proves uptime. Preserve empty queues, skipped checks, unavailable signals, unresolved work, and unproven claims honestly. Production changes, issue-tracker writes, monitoring changes, deploys, rollbacks, paging, status communication, and customer-data access remain separate gates.
|
|
178
|
+
|
|
179
|
+
## Working Web App
|
|
180
|
+
|
|
181
|
+
Slug: `working-web-app`
|
|
182
|
+
|
|
183
|
+
Lane: `create`
|
|
184
|
+
|
|
185
|
+
Public page: `https://possible.sh/packs/working-web-app`
|
|
186
|
+
|
|
187
|
+
Use when an idea, prototype, or rough repository needs to become a small locally runnable web product with one complete verified user flow—not a launch campaign or deployment.
|
|
188
|
+
|
|
189
|
+
Outputs: locally runnable working application, primary-flow and state contract, reproducible fixtures or demo data, automated checks, production build, evidence report.
|
|
190
|
+
|
|
191
|
+
Workstreams:
|
|
192
|
+
|
|
193
|
+
- Product flow and states — `frontend-design`; owns `product/flow.md`, `product/states.md`, and `product/data-contract.md`.
|
|
194
|
+
- Working application — `frontend-design`; owns application source, fixtures, and the production build.
|
|
195
|
+
- Automated product proof — `webapp-testing`; owns tests, the repeatable verification command, and the implementation receipt.
|
|
196
|
+
- Fresh review — `webapp-testing`, `security-review`; verifies the integrated app and reports scoped risks without claiming security.
|
|
197
|
+
|
|
198
|
+
Sources:
|
|
199
|
+
|
|
200
|
+
- `anthropics/skills`: `frontend-design`, `webapp-testing`; reviewed `fa0fa64bdc967915dc8399e803be67759e1e62b8`.
|
|
201
|
+
- `github/awesome-copilot`: `security-review`; reviewed `26fe2d126bf79aafb38f43344d450b69632200f8`.
|
|
202
|
+
|
|
203
|
+
Install:
|
|
204
|
+
|
|
205
|
+
```bash
|
|
206
|
+
npx skills@1.5.19 add anthropics/skills --skill frontend-design --skill webapp-testing --agent codex
|
|
207
|
+
npx skills@1.5.19 add github/awesome-copilot --skill security-review --agent codex
|
|
208
|
+
```
|
|
209
|
+
|
|
210
|
+
Prove clean local setup, one complete user job, one material failure path, every promised state and persistence boundary, a production build, responsive browser behavior, and an exact receipt. Deployment, publishing, analytics, third-party services, and real customer data remain separate gates. Never call a local build secure, scalable, reliable, or production-ready.
|
|
211
|
+
|
|
212
|
+
## Production Web Release
|
|
213
|
+
|
|
214
|
+
Slug: `production-web-release`
|
|
215
|
+
|
|
216
|
+
Lane: `release`
|
|
217
|
+
|
|
218
|
+
Public page: `https://possible.sh/packs/production-web-release`
|
|
219
|
+
|
|
220
|
+
Use when an existing tested web app needs a gated, reversible production release with an immutable candidate, verified preview, exact approval, rollback path, post-deploy smoke evidence, and final receipt. Automated execution initially supports Vercel; other providers stop at a provider-neutral no-go receipt until a reviewed adapter exists.
|
|
221
|
+
|
|
222
|
+
Outputs: pinned release candidate and provider inventory, security and pipeline preflight, rollout and rollback plan, preview smoke receipt, approved production deployment or no-go receipt, post-deployment evidence, final release receipt.
|
|
223
|
+
|
|
224
|
+
Workstreams:
|
|
225
|
+
|
|
226
|
+
- Candidate and release readiness — `devops-rollout-plan`, `security-review`; owns the candidate record, preflight, rollout plan, and rollback plan.
|
|
227
|
+
- Provider and delivery path — `github-actions-hardening`; owns provider evidence, pipeline review, and exact deploy commands. The captain holds `deploy-to-vercel` until the separate exact production approval.
|
|
228
|
+
- Release verification — `webapp-testing`; owns repeatable preview, production, and rollback-recovery checks and receipts.
|
|
229
|
+
- Fresh review — `webapp-testing`, `devops-rollout-plan`; verifies the integrated release evidence before any promotion.
|
|
230
|
+
|
|
231
|
+
Sources:
|
|
232
|
+
|
|
233
|
+
- `github/awesome-copilot`: `devops-rollout-plan`, `github-actions-hardening`, `security-review`; reviewed `26fe2d126bf79aafb38f43344d450b69632200f8`.
|
|
234
|
+
- `anthropics/skills`: `webapp-testing`; reviewed `fa0fa64bdc967915dc8399e803be67759e1e62b8`.
|
|
235
|
+
- `vercel-labs/agent-skills`: `deploy-to-vercel`; reviewed `f8a72b9603728bb92a217a879b7e62e43ad76c81`.
|
|
236
|
+
|
|
237
|
+
Install:
|
|
238
|
+
|
|
239
|
+
```bash
|
|
240
|
+
npx skills@1.5.19 add github/awesome-copilot --skill devops-rollout-plan --skill github-actions-hardening --skill security-review --agent codex
|
|
241
|
+
npx skills@1.5.19 add anthropics/skills --skill webapp-testing --agent codex
|
|
242
|
+
npx skills@1.5.19 add vercel-labs/agent-skills --skill deploy-to-vercel --agent codex
|
|
243
|
+
```
|
|
244
|
+
|
|
245
|
+
Pack confirmation does not authorize production. Workstreams prepare evidence first; the captain integrates it, records go or no-go, and asks again for approval naming the provider, account or team, project, production target, exact candidate, method, and accepted risks. Do not mutate provider state, secrets, databases, DNS, billing, repositories, or workflows without approval for that exact action. Never infer success, availability, security, or rollback readiness from a plan or one browser pass.
|
|
246
|
+
|
|
146
247
|
## Selection rule
|
|
147
248
|
|
|
148
249
|
Recommend the pack whose finished outputs most closely match the user's desired end state:
|
|
149
250
|
|
|
251
|
+
- Web-app idea or rough repository plus its first complete locally verified user flow → Working Web App.
|
|
252
|
+
- Browser-game idea plus one polished playable build → Playable Web Game.
|
|
150
253
|
- Physical product plus launch presentation → Hardware Launch.
|
|
151
254
|
- Software product plus release and launch presentation → Software Launch.
|
|
152
255
|
- Existing repository plus trustworthy public release materials → Open-Source Release.
|
|
153
|
-
-
|
|
256
|
+
- Existing tested web app plus a reversible approved production deployment and smoke receipt → Production Web Release.
|
|
257
|
+
- Live web app plus a repeatable reliability, issue-triage, maintenance, incident-response, and safe-change cadence → Web App Operations.
|
|
258
|
+
|
|
259
|
+
Use Working Web App when the missing outcome is the product itself. Use Software Launch when the product works and the missing outcome is its public story, site, and demo. Use Production Web Release when a tested candidate exists and the missing outcome is a gated production promotion with rollback and smoke evidence. Use Web App Operations only after the app is live and the desired outcome is an ongoing rhythm. A distributable repository release belongs to Open-Source Release; one isolated bug or incident with no requested recurring workflow is focused work, not a pack.
|
|
154
260
|
|
|
155
261
|
If none fits, say so. Do not force a pack or invent a new one during intake.
|