re-frame2-implementor
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Engineering
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: re-frame2-implementor
description: > Use when this capability is needed. This skill is workflow + guidance layered on the spec corp…
category: engineering
runtime: no special runtime
---
# re-frame2-implementor output preview
## PART A: Task fit
- Use case: > Use when this capability is needed. This skill is workflow + guidance layered on the spec corpus at spec/. The spec is the contract; the reference impl under implementation/ is one worked example, not normative. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When NOT to use this skill / Cardinal rules (one-liners; full text in [references/cardinal-rules.md](references/cardinal-rules.md)) / Phase 1 — lock the decisions” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Use when this capability is needed. This skill is workflow + guidance layered on the spec corpus at spec/. The spec is the contract; the reference impl under implementation/ is one worked example, not normative. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “When NOT to use this skill / Cardinal rules (one-liners; full text in [references/cardinal-rules.md](references/cardinal-rules.md)) / Phase 1 — lock the decisions” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “When NOT to use this skill / Cardinal rules (one-liners; full text in [references/cardinal-rules.md](references/cardinal-rules.md)) / Phase 1 — lock the decisions”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: re-frame2-implementor
description: > Use when this capability is needed. This skill is workflow + guidance layered on the spec corp…
category: engineering
source: tomevault-io/skills-registry
---
# re-frame2-implementor
## When to use
- > Use when this capability is needed. This skill is workflow + guidance layered on the spec corpus at spec/. The spec…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When NOT to use this skill / Cardinal rules (one-liners; full text in [references/cardinal-rules.md](references/cardinal-rules.md)) / Phase 1 — lock the decisions” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "re-frame2-implementor" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When NOT to use this skill / Cardinal rules (one-liners; full text in [references/cardinal-rules.md](references/cardinal-rules.md)) / Phase 1 — lock the decisions
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} re-frame2-implementor
This skill is workflow + guidance layered on the spec corpus at spec/. The spec is the contract; the reference impl under implementation/ is one worked example, not normative.
The job is to walk the engineer through two phases:
- Phase 1 — lock the load-bearing decisions (target language, substrate, scope, identity primitive, persistent data, concurrency, schema mechanism, hot-reload).
- Phase 2 — implement EPs in dependency order (001 → 002 → 006 → 004 → 009, then optional EPs per Phase 1 scope), validated by the conformance corpus.
When NOT to use this skill
Full skill-disambiguation matrix lives at skills/README.md §Skill routing — single source. In brief: not for authoring on the CLJS reference, greenfield bootstrap, v1→v2 migration, live-app inspection, or pattern-rationale reading.
Cardinal rules (one-liners; full text in references/cardinal-rules.md)
- Spec is the contract. When
implementation/andspec/disagree, the spec wins. - Phase 1 before Phase 2. Lock decisions in writing before writing code.
- Dependency order. EP 001 → 002 → 006 → 004 → 009 are the foundation; optional EPs sit downstream.
- Substrate-agnostic phrasing. Write to "the identity primitive", "the render-tree", "the reactive container" — not to hiccup / Reagent / keywords.
- No core.async equivalents. Async effects ride host primitives; cross-frame work is run-to-completion-drained.
- JVM-runnability for testing. Pure transitions and pure sub computations must be callable from a non-substrate harness.
- Conformance corpus is the acceptance test. Score is
passed / claimed-applicable; a fixture you can't make pass without outside sources is a spec gap. - Spec gap → draft a GitHub issue against
day8/re-frame2and ask before filing. Don't paper, don't invent, don't extrapolate from the reference — but don't auto-file either. Show the engineer the drafted title + body, restrict the body to public spec-quoted evidence (no private port source), and wait for explicit OK before runninggh issue create. The skill runs in the engineer's port repo; spec gaps reach the framework maintainers via the upstream repo's GitHub issues — never viabd(re-frame2's internal tracker, never invoked from a published skill). - Per-issue approval gate for any cross-repo side effect. Before running
gh issue createagainst a repo other than the one the engineer is working in, show the full draft (title, target repo, label set, body) and wait for explicit "yes" / "go" / "file it". Invoking the skill is consent to the workflow, not to each cross-repo write. Seereferences/cardinal-rules.md§9. - Pin the spec corpus. The kickoff prompt names a specific
day8/re-frame2commit/tag; verify the checkout's HEAD and origin before reading the spec, and record the pinned hash inDECISIONS.md(preamble before D1). An unverified checkout is not the contract. - Honour the reserved
:rf/*scheme. Framework-owned ids live under the single root namespace:rf/*(and its sub-namespaces); user code MUST NOT register under:rf/*. Reserved fx-ids and reserved app-db keys (:rf/machines,:rf/route, …) are part of the contract. A port that ignores the scheme fails conformance fixtures that assert:rf.*operation ids. Perspec/Conventions.md; the "where does each surface live" map isspec/Ownership.md.
Phase 1 — lock the decisions
Walk references/phase-1-decisions.md and produce a locked-decision record using the references/decision-record.md template. The seven decision blocks (D1 target language, D2 substrate, D3 scope, D4 the always-required realisation decisions — Implementor-Checklist Part 2's F1–F6 / S1–S3 / Sub1–Sub2 / V1–V3 / T1–T3 / E1–E2, sub-numbered 1:1 with the checklist, D5 schema mechanism, D6 integration story, D7 capability tag set) are detailed there; the canonical option matrices live in spec/Implementor-Checklist.md.
Output of Phase 1: a single dated decision record committed to the port's own repo.
Phase 2 — walk the spec corpus
With Phase 1 locked, walk references/phase-2-impl-order.md EP-by-EP. The leaf carries, for each EP: what to read first, the contract to expose, how the CLJS reference realised it (as one example, not normative), what the conformance fixtures check, common spec-gap traps.
Dependency order is fixed: EP 001 Registration → 002 Frames → 006 Reactive substrate → 004 Views → 009 Instrumentation, then a first conformance pass against the :core/* fixtures. Optional EPs (010 Schemas, 008 Testing, 005 State machines, 012 Routing, 011 SSR, 013 Flows, 014 HTTP, 007 Stories) follow in the order Phase 1 declared yes for them.
Source discipline
Three tiers, in priority order:
spec/— the contract. Read in numeric order.spec/Implementor-Checklist.md— the decision-ordered companion.implementation/— a worked example. Useful for "how did someone solve X?" Never useful as a contract claim.
If implementation/ and spec/ disagree, the spec wins.
Conformance
The corpus at spec/conformance/ is host-agnostic data. Harness shape, the EDN-handler-body DSL, capability tagging, scoring, and the spec-gap-vs-implementation-bug distinction are all in references/conformance.md. The corpus is the acceptance test for Goal 2 — AI-implementable from the spec alone.
Kickoff and output
references/kickoff-prompt.md— paste-ready prompt for the engineer to drop into a fresh Claude session opened in the root of their port repo.references/output-format.md— the standard agent-output shape: implementation summary, capability tags claimed, conformance score, decisions made, spec gaps filed.
Done — "v1-complete against <capability tag set>"
- Phase 1 decision record committed to the port's repo.
- All in-scope EPs have a working implementation.
- The port exposes
spec/API.md, adapted to host idiom. - Conformance score is
(claimed-applicable) / (claimed-applicable). - Non-spec-gap failures fixed in the port; spec-gap failures filed as GitHub issues against
day8/re-frame2. - Port's README states claimed capability tags and conformance score.
Reference files (all one level deep)
references/cardinal-rules.md— the eleven rules in prose + anti-pattern corollaries.references/phase-1-decisions.md— Phase 1 walkthrough, seven decision blocks.references/decision-record.md— fill-in template for the locked-decision record.references/phase-2-impl-order.md— EP-by-EP implementation order.references/reference-impl-tour.md— guided tour of the CLJS reference; what's substrate-specific vs pattern-required.references/conformance.md— corpus harness, DSL, capability tagging, scoring.references/kickoff-prompt.md— fresh-session kickoff prompt.references/output-format.md— agent-output shape.
Authoritative contract: spec/. Decision companion: spec/Implementor-Checklist.md. Conformance: spec/conformance/. CLJS reference (worked example): implementation/. Full skill-disambiguation matrix: skills/README.md §Skill routing — single source.
Source: day8/re-frame2 — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review