@fraylabs/possible 0.1.1 → 0.1.3
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, or operate, wants help defining an outcome before implementation, or wants a Hardware Launch, Software Launch, Open-Source Release, Playable Web Game, or Web App Operations outcome coordinated end to end.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# Possible
|
|
@@ -31,7 +31,7 @@ Inspect the project read-only when it can answer a question. Do not ask the user
|
|
|
31
31
|
|
|
32
32
|
During the brainstorm:
|
|
33
33
|
|
|
34
|
-
- Do not mention pack names or ingredient skills.
|
|
34
|
+
- Do not mention pack names, lanes, or ingredient skills.
|
|
35
35
|
- Do not create `PRODUCT-BRIEF.md`, `RUN-PROMPT.md`, or `AGENTS.md`.
|
|
36
36
|
- Do not install dependencies, edit files, or spawn subagents.
|
|
37
37
|
- Do not invent facts to make the idea appear more complete.
|
|
@@ -42,6 +42,8 @@ After the walkthrough, read [references/packs.md](references/packs.md). If `list
|
|
|
42
42
|
|
|
43
43
|
Recommend one primary pack. Use multiple packs only when the user has explicitly described multiple independently valuable outcomes; stage them instead of merging their workstreams.
|
|
44
44
|
|
|
45
|
+
A lane is catalog browsing metadata, not an intake choice. Do not ask the user to choose a lane; recommend across the complete catalog from the desired finished outcome.
|
|
46
|
+
|
|
45
47
|
Keep the recommendation compact and conversational. Present:
|
|
46
48
|
|
|
47
49
|
1. **What I think you want to make** — a brief outcome statement and any material assumption.
|
|
@@ -89,6 +91,8 @@ When invoked as `$possible resume`, look for `.possible/outcome-brief.md`, `.pos
|
|
|
89
91
|
- If the brief exists but the pack or lock does not, return to recommendation or installation without repeating answered questions.
|
|
90
92
|
- If no Possible state exists, begin with the intake question.
|
|
91
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
|
+
|
|
92
96
|
## Boundaries
|
|
93
97
|
|
|
94
98
|
- Pack confirmation authorizes only the disclosed repo-local skill installation and local artifact work.
|
|
@@ -2,10 +2,14 @@
|
|
|
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.
|
|
6
|
+
|
|
5
7
|
## Hardware Launch
|
|
6
8
|
|
|
7
9
|
Slug: `hardware-launch`
|
|
8
10
|
|
|
11
|
+
Lane: `launch`
|
|
12
|
+
|
|
9
13
|
Public page: `https://possible.sh/packs/hardware-launch`
|
|
10
14
|
|
|
11
15
|
Use for a physical-product idea or prototype that needs one coherent launch presentation.
|
|
@@ -41,6 +45,8 @@ Never imply manufacturing readiness, physical validation, certification, or cust
|
|
|
41
45
|
|
|
42
46
|
Slug: `software-launch`
|
|
43
47
|
|
|
48
|
+
Lane: `launch`
|
|
49
|
+
|
|
44
50
|
Public page: `https://possible.sh/packs/software-launch`
|
|
45
51
|
|
|
46
52
|
Use for an existing software idea or repository that needs a coherent product release and launch presentation.
|
|
@@ -75,6 +81,8 @@ Never imply demand, uptime, security, performance, or production readiness. Depl
|
|
|
75
81
|
|
|
76
82
|
Slug: `open-source-release`
|
|
77
83
|
|
|
84
|
+
Lane: `release`
|
|
85
|
+
|
|
78
86
|
Public page: `https://possible.sh/packs/open-source-release`
|
|
79
87
|
|
|
80
88
|
Use for an existing repository that needs a trustworthy, usable release package without publishing it.
|
|
@@ -104,6 +112,8 @@ Never imply security, compatibility, production readiness, or release authority.
|
|
|
104
112
|
|
|
105
113
|
Slug: `playable-web-game`
|
|
106
114
|
|
|
115
|
+
Lane: `create`
|
|
116
|
+
|
|
107
117
|
Public page: `https://possible.sh/packs/playable-web-game`
|
|
108
118
|
|
|
109
119
|
Use for a browser-game idea that needs one polished, replayable Three.js experience rather than a general game engine or sprawling feature set.
|
|
@@ -133,6 +143,39 @@ npx skills@1.5.19 add anthropics/skills --skill frontend-design --skill webapp-t
|
|
|
133
143
|
|
|
134
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.
|
|
135
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
|
+
|
|
136
179
|
## Selection rule
|
|
137
180
|
|
|
138
181
|
Recommend the pack whose finished outputs most closely match the user's desired end state:
|
|
@@ -141,5 +184,8 @@ Recommend the pack whose finished outputs most closely match the user's desired
|
|
|
141
184
|
- Software product plus release and launch presentation → Software Launch.
|
|
142
185
|
- Existing repository plus trustworthy public release materials → Open-Source Release.
|
|
143
186
|
- Browser-game idea plus one polished playable build → Playable Web Game.
|
|
187
|
+
- Live web app plus a repeatable reliability, issue-triage, maintenance, incident-response, and safe-change cadence → Web App Operations.
|
|
188
|
+
|
|
189
|
+
Use Web App Operations only when the app already exists and the desired outcome is an ongoing rhythm. An initial build or public launch belongs to Software Launch; 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.
|
|
144
190
|
|
|
145
191
|
If none fits, say so. Do not force a pack or invent a new one during intake.
|