Prompt Craft

Turn a noisy 24-hour market window into a decision-ready morning brief.

                  You are a crypto market analyst supporting a protocol operations team.

Research the past 24 hours for [sector] and produce a source-backed intelligence brief.

Check:
1. The top three gainers and losers in [sector], including 24-hour change, market capitalization, and liquidity context.
2. TVL changes greater than 5% among the ten largest protocols in [sector].
3. Exploits, governance votes, listings, integrations, funding, or partnership announcements.
4. Material sentiment shifts around [three to five keywords]. Separate observed evidence from interpretation.

For every claim, include a direct source URL and its publication or observation time. If sources conflict or data is unavailable, state that explicitly. Do not invent missing figures.

Format:
## What Changed
## Steady State
## Requires a Decision
## Watch Next
## Sources
                

Compare positioning, product moves, and distribution across a focused peer set.

                  Act as a competitive intelligence lead for [protocol].

Compare [protocol] with [competitor 1], [competitor 2], and [competitor 3] over [time period]. Evaluate:
- Positioning and primary user promise
- Recent product or chain launches
- Incentives, fees, and token utility
- Distribution channels and partner ecosystem
- Developer, user, and liquidity traction
- Risks or weaknesses visible in public evidence

Use primary sources first: official documentation, governance forums, repositories, dashboards, and announcement posts. Cite every time-sensitive statement with a direct URL and date. Label estimates and inferences.

Return a comparison table, three meaningful changes, two threats, two opportunities, and one recommended action for the next seven days.
                

Investigate a metric spike without confusing correlation for cause.

                  You are investigating an unusual movement in [metric] for [protocol or token] at [timestamp].

Build an evidence trail:
1. Establish the normal baseline for the previous [30] days.
2. Quantify the anomaly by size, duration, wallet concentration, and affected contracts or pools.
3. Test plausible explanations: incentives, migrations, whale activity, liquidations, exploits, oracle issues, and data-pipeline errors.
4. Cross-check at least two independent data sources.
5. Identify what evidence would disprove each leading hypothesis.

Do not imply causation without transaction-level evidence. Include query links, transaction hashes, contract addresses, and timestamps where available.

Output: Observed Facts, Hypotheses Ranked by Confidence, Missing Evidence, Risk Assessment, and Next Queries to Run.
                

Turn a long governance proposal into an actionable risk memo.

                  Review the following governance proposal for [DAO]: [proposal URL or text].

Analyze it as an independent governance researcher. Cover:
- The requested change and its stated objective
- Treasury, token, smart-contract, legal, and operational impact
- Who benefits, who bears risk, and any conflicts of interest
- Reversible versus irreversible consequences
- Implementation dependencies and monitoring requirements
- Relevant precedents from this DAO or comparable protocols

Quote only the minimum necessary text and link to primary evidence. Flag unclear parameters and assumptions. Do not recommend a vote until the unresolved questions are listed.

Format a one-page memo with: Executive Summary, Impact Table, Critical Questions, Failure Modes, Safeguards, and a conditional Vote Recommendation.
                

Assess launch readiness across market, product, liquidity, and operations.

                  Act as a skeptical launch-readiness reviewer for [project] before its planned token launch on [date].

Evaluate evidence in five areas:
1. Product usage: active users, retention, transaction quality, and organic versus incentivized activity.
2. Distribution: community composition, partner readiness, exchange or venue dependencies, and geographic concentration.
3. Token design: allocation, unlocks, utility, governance, liquidity, and holder incentives.
4. Operations: incident response, support coverage, communications approvals, dashboards, and owner assignments.
5. Market context: comparable launches, liquidity conditions, and narrative saturation.

For each item, classify evidence as Verified, Partial, Missing, or Not Applicable and link the source. Never fill gaps with assumptions.

Finish with launch blockers, mitigations, accountable owners, and a go / conditional go / no-go recommendation.
                

Turn a keyword into a useful argument, not a generic list of headings.

                  You are a content strategist and SEO editor for a crypto operator publication.

Target keyword: [keyword]
Search intent: [informational / commercial / navigational]
Audience: [describe the reader and their level]
Desired action: [what the reader should do]
Target length: [word count]

Create:
1. One H1 under 60 characters that naturally includes the keyword.
2. A 150-160 character meta description.
3. A one-sentence thesis and the reader's core tension.
4. Five to seven H2 sections, each with its argument, proof needed, and two or three H3s where useful.
5. Three opportunities for original data, operator examples, diagrams, or templates.
6. Suggested internal links to relevant pages on [domain].
7. Claims that require external verification and the ideal primary source type for each.

Avoid keyword stuffing, invented statistics, and headings that repeat the same idea.
                

Convert a raw interview into a credible narrative with evidence gaps exposed.

                  You are editing a case study for [company or protocol]. Use the interview transcript below without inventing details.

[Paste transcript]

Extract:
- The initial situation and measurable constraint
- The decision or intervention
- Implementation steps and responsible roles
- Results, including timeframe and baseline
- Trade-offs, failures, and lessons

Draft a case study with: Headline, Executive Summary, Context, Turning Point, What Changed, Results, and Operator Lessons. Attribute direct quotes accurately. Mark unsupported claims as [VERIFY] and list the evidence needed, such as dashboard screenshots, transaction links, or customer references.

Keep the tone specific, restrained, and useful. Do not turn the subject into a hero or hide negative outcomes.
                

Explain a product release clearly without flattening the technical details.

                  You are writing an X thread for the launch of [feature or product].

Inputs:
- Audience: [users / developers / partners]
- Problem solved: [problem]
- How it works: [technical explanation]
- Proof: [benchmarks, transactions, demo, repository, or documentation]
- Limitations: [known constraints]
- Call to action: [desired next step]

Write 7-10 posts. The first post must state the user outcome, not announce that an announcement exists. Use one idea per post, explain necessary technical terms, and place evidence links next to the claim they support. Include one post on limitations or trade-offs.

Return the thread, a suggested visual for each post, and a final fact-check list. Do not invent adoption metrics or partner endorsements.
                

Adapt one strong source into channel-native assets without copying it blindly.

                  Act as a distribution editor. Repurpose the source material below for distinct channels while preserving its factual meaning.

[Paste article, research note, podcast transcript, or memo]

Audience: [describe]
Primary insight: [optional]
Brand voice: [three adjectives]

Produce:
1. A 5-post LinkedIn carousel outline.
2. A 7-post X thread.
3. A 120-word newsletter opening.
4. Three community discussion prompts.
5. A 45-second short-video script.

Each asset must use the conventions of its channel, lead with a different angle, and point back to the source. Preserve caveats and citations. List any statement that cannot be traced to the source instead of adding it.
                

Audit a crypto draft for weak evidence, ambiguity, and accidental hype.

                  You are a rigorous fact-checker reviewing a crypto article before publication.

[Paste draft]

Inspect every factual statement, number, date, named entity, quotation, superlative, and causal claim. Create a table with:
- Exact claim
- Claim type
- Verification status: Supported / Partially Supported / Unsupported / Time-Sensitive
- Best available source URL
- Required correction or caveat

Prefer primary sources and note the access date for live metrics. Check that linked sources actually support the adjacent claim. Identify vague language, promotional framing, and missing counterarguments.

Then provide a corrected version of only the problematic passages. Never fabricate a citation or silently remove uncertainty.
                

Convert raw weekly signals into an accountable operating review.

                  You are an operations analyst. Generate a weekly review from the evidence below.

Week ending: [date]
Objectives: [list]
Features or deliverables shipped: [list with links]
Blocked items: [owner, blocker, age]
Metric changes: [current, baseline, source]
Incidents or support themes: [list]
Team confidence: [1-5 with comments]

Compare results with the previous baseline. Distinguish completed work from activity and flag changes outside normal variance. If a metric is missing or definitions changed, say so.

Format:
## Executive Readout
## Shipped and Verified
## Blocked / At Risk
## Metrics Watch
## Decisions Made
## Next Week: Owner + Outcome + Due Date
## Confidence and Data Gaps
                

Create a calm, time-boxed response plan during a protocol incident.

                  You are coordinating an active incident for [protocol or product].

Known facts: [facts with timestamps]
Unknowns: [list]
Affected systems or users: [scope]
Current mitigations: [actions and owners]

Create an incident plan that includes:
1. Severity classification and the evidence supporting it.
2. A 30-minute action sequence with one owner per action.
3. A decision log template with timestamps.
4. Internal and public update drafts that separate confirmed facts from investigation.
5. Evidence preservation steps.
6. Recovery criteria, monitoring, and post-mortem ownership.

Do not speculate about cause, loss, or attribution. Explicitly mark placeholders and approval gates. Safety-critical actions must require a qualified human owner.
                

Turn scattered notes into a testable standard operating procedure.

                  You are an operations designer. Convert the notes below into an SOP that a new teammate can execute safely.

[Paste notes, transcript, or chat history]

Define:
- Purpose and success condition
- Trigger and expected frequency
- Required access, inputs, and prerequisites
- Numbered execution steps with an owner or role
- Validation after each irreversible or external action
- Failure states, escalation path, and rollback where possible
- Final evidence required for completion
- Review cadence and document owner

Separate facts present in the source from inferred steps. Label every inference [CONFIRM]. Never include secrets, private keys, or live credentials. Add a dry-run checklist and a short handoff test for a first-time operator.
                

Define owners, gates, and evidence before a high-stakes launch begins.

                  Build an operator-grade war-room plan for [launch] scheduled for [date and timezone].

Teams involved: [list]
Critical dependencies: [list]
Known risks: [list]
Communication channels: [list]

Create:
1. T-7 day, T-24 hour, T-60 minute, launch, and T+24 hour checklists.
2. A RACI table for product, engineering, security, growth, community, support, and leadership.
3. Go / no-go gates with measurable evidence.
4. A live issue log format with severity, owner, ETA, and next update.
5. Internal, partner, and public communication templates.
6. Rollback triggers and the authority required to invoke them.

Use absolute timestamps. Do not mark a gate complete without the named artifact, link, or approver.
                

Stress-test an automation before its original builder steps away.

                  Review the automation described below for production handoff.

Workflow: [description]
Trigger and schedule: [details]
Systems touched: [list]
Inputs and outputs: [list]
Current owner: [role]
Logs or run history: [links]

Assess:
- Trigger reliability and idempotency
- Authentication and least-privilege access
- Input validation and unsafe edge cases
- Observability, alerting, and evidence of delivery
- Retry, timeout, fallback, and rollback behavior
- Ownership, documentation, and manual recovery

Return a risk register ranked Critical / High / Medium / Low, a pre-handoff test plan, a runbook outline, and explicit acceptance criteria. Treat a successful trigger as different from verified delivery.