artifact-from-the-future
Skill2 starsChanged 52 days agoMITView on GitHub
Render a signal, scenario or idea as a concrete object from a future date — a press release, product page, news headline set, regulator's notice, support ticket, obituary, onboarding email — in the voice of that world, so a team can react to it. Design fiction, disciplined. Use when the user asks for "a press release from 2035", "what would the headline be", "show me what this looks like", "design fiction", or needs a workshop provocation. Stage: make.
In this repository16 other files it gives its agents.
- adjacency-scanSkill
- competitive-scanSkill
- framesSkill
- grill-the-futureSkill
- groundSkill
- horizon-scanSkill
- implicationsSkill
- innovation-radarSkill
- mergeSkill
- regulatory-scanSkill
- reportSkill
- risk-radarSkill
- scenariosSkill
- scopeSkill
- signalSkill
- technology-scanSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Read first: ../../core/envisioning.md, ../../core/voice.md.
- Distinctive: line 73
No utopia, no apocalypse. If the premise only works as either, say so and offer the nearest ordinary version.
- Distinctive: line 75
Never use a real company as the subject of a failure artifact.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
artifact-from-the-future
Abstract futures don't provoke; objects do. This skill makes one object from one future, precise enough that people argue with it.
Read first: ../../core/envisioning.md, ../../core/voice.md.
Input
- Source: a scenario (name + set), a signal card, or a stated premise.
- Year: explicit, or taken from the scenario's horizon.
- Form: pick from the table or take the user's. If unspecified, choose the form that makes the premise most ordinary — a future is convincing when it is boring to the people living in it.
| form | good for |
| press release | a capability arriving |
| product page with pricing | a cost curve bending |
| three news headlines + standfirsts | a norm shifting |
| regulator's notice / recall | a backlash |
| customer support ticket | a failure mode at scale |
| job posting | a new role existing |
| onboarding email | adoption becoming default |
| obituary (of a product, practice or company) | a substitution completing |
| museum placard | the long view |
Procedure
- Anchor. Ground on the source; list 3–5 facts from the cards or
scenario that the artifact must respect. Write them in frontmatter as
anchors[]so a reader can check the fiction against the evidence. - Extrapolate one step. The artifact lives one step past the anchors, not ten. Include one detail that is mundane in the future and startling now (a price, a default setting, a line in the terms).
- Write in the world's voice. The document is written by someone in that year who does not know it is a provocation. No winking, no "in this future". Institutions have names; prices have currencies; dates are real dates.
- Keep it short. 200–400 words. A real press release is skimmed; so is this.
- Add the reading guide after the artifact, separated by a rule: three questions for the team — what here is already true? · what would have to happen for this to exist? · who in this room would fight it?
- Persist per envisioning.md.
Output
---
kind: artifact
title: <the artifact's own headline>
form: <from the table>
year: <YYYY>
scenario: <name, if from a set>
anchors: [<facts respected>]
sources: [<cards / scenario doc>]
---
<the artifact, in-world>
---
## Reading guideRefusals
- No utopia, no apocalypse. If the premise only works as either, say so and offer the nearest ordinary version.
- Never use a real company as the subject of a failure artifact. Fictional names for actors; real names only for institutions that would plausibly still exist (regulators, standards bodies).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.