# Frontier Lab

> Compose unusual, technically grounded hackathon product concepts and select a falsifiable prototype spike. Use for frontier ideation, technical novelty, or testing a risky differentiator; not routine implementation of an already chosen feature.

- Skill: `shreyp087/frontier-lab` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add shreyp087/frontier-lab`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shreyp087/frontier-lab/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Shreyp087 (https://skillmd.com/u/shreyp087)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/shreyp087/frontier-lab

---


# Frontier Lab

Turn an interesting technical possibility into one useful, demonstrable product behavior. Preserve the user's domain, event constraints, stack, and existing decisions.

## Compose the concept

- Identify the user, painful task, desired outcome, and available time, data, hardware, and budget. Infer routine defaults; surface only gaps that could change the choice.
- Combine **one outcome + one interaction + one mechanism**. Example: coordinate a community event + fork a shared plan + mergeable local data and a small constraint solver.
- Explore several genuinely different mechanisms before polishing a name. Use [composition patterns](references/patterns.md) if ideas collapse into generic chat interfaces.
- Prefer a surprising interaction that exposes a useful capability. Novelty in a pitch is insufficient when the product behavior remains unchanged.

## Verify the primitive

- Check the current maintainer documentation, repository, or original paper for the exact capability needed. Record URL, check date, supported environment, maturity, and the important limitation.
- Distinguish “the library exposes this primitive” from “our proposed composition works.” Research papers and videos inspire concepts; current docs and a running spike establish implementation feasibility.
- Before depending on an integration, inspect authentication, quotas/cost, data rights, license, required hardware, and whether a local fixture can demonstrate the mechanism.
- Keep source caveats attached to the idea: provenance is not factual truth; CRDT convergence is not semantic agreement; simulation is not validated prediction; model availability is not acceptable latency; automated accessibility checks are partial.

## Select a spike

For each serious candidate, create a short card with:

1. User outcome and current workaround.
2. Interaction and verified enabling primitive.
3. The hardest unproven assumption.
4. A **two-hour spike**, or the user's timebox, that can falsify that assumption.
5. A concrete input, expected visible output, measured threshold, and fallback.
6. A 90-second demo sequence plus a live variation the audience can request.

Rank candidates by user value, distinctiveness, proof clarity, two-hour feasibility, and dependency risk. Use ordinal judgments with rationale; do not invent numerical win probabilities. Separate a feasible core from ambitious extensions. Reject candidates whose main capability must be mocked to appear functional.

## Test the hardest claim

- When implementation is authorized, build the smallest end-to-end experiment before branding or broad scaffolding. Avoid installing a collection of unrelated dependencies.
- Use representative fixtures and the actual target environment. Record observed latency, quality, resource use, or failure rate relevant to the claim.
- Include one meaningful variation or failure: network unavailable, concurrent edit, ambiguous input, unsupported device, invalid source, or infeasible constraints.
- State exactly what the result establishes. Label prerecorded replay, simulated data, mocked dependencies, and untested hardware.
- Stop the spike at its agreed timebox. If the central claim fails, narrow the concept or select the next candidate rather than disguising the failure with UI.

## Deliver

Return a ranked shortlist, source-backed feasibility notes, the selected spike brief, and a demo proof plan. If a spike was run, report the observed result and link its artifact. A compelling concept may remain a proposal; distinguish it from configured tooling or working implementation.