Back to Details

tk-prototype

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Comparison Prototype

对比原型

Apply to explicit 
invocation
or executable 
disposable
comparison/
harness
requests. Do not auto-apply to 
production implementation
or conversational exploration.
Accept a 
prompt
, idea, screenshot, 
spec
, 
ticket
, code, or design reference as input. Write under 
.tigerkit/prototypes/<slug>/
unless a temporary 
route
/
harness
is more useful. Create parent directories only when needed, replace atomically when possible, and do not automatically archive or edit 
.gitignore
. Warn if the 
scratch
path is tracked. 실행 전 temporary path, data boundary, verification question 또는 variant 선택이 필요하면 host별 native structured question surface를 우선 사용합니다 (Claude Code: AskUserQuestion; Codex: request_user_input; Hermes: clarify). unavailable하면 같은 확인을 plain chat으로 fallback하고 실행 후 비교 보고에는 question surface를 호출하지 않습니다.
适用于明确的
invocation
或可执行的
disposable
对比/
harness
请求。 请勿自动应用于
production implementation
或对话式探索场景。
接受
prompt
、创意想法、截图、
spec
、
ticket
、代码或设计参考作为输入。 除非临时
route
/
harness
更实用，否则请写入
.tigerkit/prototypes/<slug>/
目录下。仅在需要时创建父目录，尽可能以原子方式替换文件，且不要自动归档或编辑
.gitignore
。若
scratch
路径被追踪，请发出警告。
执行前若需要选择临时路径、数据边界、验证问题或变体，请优先使用各宿主原生的结构化提问界面（Claude Code：AskUserQuestion；Codex：request_user_input；Hermes：clarify）。若无法使用，则通过普通聊天进行同样的确认，执行后的对比报告中不再调用提问界面。

Workflow

工作流程

  1. hypothesis/success criteria
    : Derive measurable criteria from the idea, reference, and verification question.
  2. temporary path/boundary
    : Inspect repository preflight and select the existing toolchain/UI stack/component/token, temporary path, artifact ownership, and 
    fake | real
    integration boundary.
  3. variants/harness
    : Create 2–3 
    variant
    s or a 
    harness
    using realistic example I/O.
  4. run
    : Execute the selected 
    variant
    /
    harness
    and capture actual output or screenshots and command results.
Record each run under 
## Tested
with the following receipt fields. Do not summarize the command; record the exact executed values.
text
Command: <exact command and arguments>
CWD: <absolute worktree or route path>
Exit code: <integer>
Output: <bounded summary or absolute output path>
Artifact: <absolute path | none>; ownership: run-owned | pre-existing
Screenshot: <absolute path | N/A>; actual inspection: yes | no | N/A
  1. compare
    : Map evidence to criteria and summarize verified differences, unverified items, and the next decision. If the parent contract records 
    PR evidence: required
    , retain the run-owned absolute 
    Screenshot: <path>
    and actual image inspection under 
    ## Tested
    , and expose a bounded handoff containing 
    evidence_required: true
    , the criterion, evidence directory, and producer 
    tk-prototype
    . This proves the comparison, not an official runtime verdict.
  2. terminal summary
    : Render the applicable sections under the output contract below; do not add a separate provenance/status block.
For unresolved UI comparisons, create 2–3 switchable, genuinely different rendered alternatives. Do not change only colors; vary information architecture, flow, hierarchy, navigation, or feedback. For logic, prefer a small pure harness using example input/output and a minimal adapter.
For a web prototype, inspect the repository's run command, installed UI stack, components, and design tokens. Reuse a safe isolated route/harness without adding dependencies or changing manifest/lockfiles. If none exists, use a small 
.tigerkit/prototypes/<slug>/index.html
, 
styles.css
, and 
app.js
.
Compare 2–3 decision-relevant concepts while keeping content, data, and interaction state identical. Default to 2–3 side-by-side columns on wide screens and stacked on narrow screens. Use an explicit A/B or A/B/C toggle only when simultaneous rendering would harm the concept or minimum legibility. Stop at A/B when a third option adds no independent value. Do not create a prototype when repository evidence already resolves the decision.
Verify web output through 
tk-browser-verify
, including actual interaction, the 
run URL
/
command
, and 
success-criteria
screenshots. If a development server is required, 
handoff
the exact 
command
/
cwd
/target URL/
auth mode
/
readiness
condition; 
tk-browser-verify
owns server start, wait, and shutdown. Check both wide and narrow only when the 
hypothesis
concerns responsiveness/layout. Clean up only run-owned tracked 
harness
files; preserve any 
existing route
, 
dependency
, and 
production source
.
  1. hypothesis/success criteria
    ：从创意、参考资料和验证问题中推导可衡量的标准。
  2. temporary path/boundary
    ：预检代码仓库，选择现有工具链/UI栈/组件/令牌、临时路径、制品归属权以及
    fake | real
    集成边界。
  3. variants/harness
    ：使用真实示例输入输出创建2–3个
    variant
    或一个
    harness
    。
  4. run
    ：执行选中的
    variant
    /
    harness
    ，捕获实际输出或截图以及命令执行结果。
将每次运行记录在
## Tested
部分下，包含以下回执字段。请勿总结命令，需记录确切的执行值。
text
Command: <确切的命令及参数>
CWD: <绝对工作树或路由路径>
Exit code: <integer>
Output: <有限摘要或绝对输出路径>
Artifact: <绝对路径 | 无>; ownership: run-owned | pre-existing
Screenshot: <绝对路径 | N/A>; actual inspection: yes | no | N/A
  1. compare
    ：将证据映射到标准，总结已验证的差异、未验证项以及下一步决策。若父合约记录
    PR evidence: required
    ，则在
    ## Tested
    部分保留运行生成的绝对路径
    Screenshot: <path>
    和实际图像检查记录，并提供包含
    evidence_required: true
    、标准、证据目录和生成者
    tk-prototype
    的有限交接内容。这仅用于证明对比过程，而非正式的运行时结论。
  2. terminal summary
    ：根据下方的输出合约渲染适用部分；请勿添加单独的来源/状态块。
对于未解决的UI对比，创建2–3个可切换、真正不同的渲染替代方案。请勿仅更改颜色；需调整信息架构、流程、层级、导航或反馈方式。对于逻辑原型，优先使用包含示例输入输出和最小适配器的小型纯测试框架。
对于Web原型，检查仓库的运行命令、已安装的UI栈、组件和设计令牌。复用安全隔离的路由/测试框架，无需添加依赖或修改清单/锁文件。若不存在此类路由/框架，则使用小型的
.tigerkit/prototypes/<slug>/index.html
、
styles.css
和
app.js
。
在保持内容、数据和交互状态完全一致的前提下，对比2–3个与决策相关的概念。默认在宽屏上显示2–3个并排列，窄屏上显示堆叠布局。仅当同时渲染会影响概念表达或最低可读性时，才使用明确的A/B或A/B/C切换器。当第三个选项无法带来独立价值时，仅保留A/B对比。若仓库已有证据可解决决策问题，则无需创建原型。
通过
tk-browser-verify
验证Web输出，包括实际交互、
run URL
/
command
和
success-criteria
截图。若需要开发服务器，则交接确切的
command
/
cwd
/目标URL/
auth mode
/
readiness
条件；
tk-browser-verify
负责服务器的启动、等待和关闭。仅当
hypothesis
涉及响应式/布局时，才同时检查宽屏和窄屏情况。仅清理运行生成的已追踪
harness
文件；保留任何
existing route
、
dependency
和
production source
。

Failure Paths

失败路径

Record pre-existing temporary paths and run-created files before writing.
ConditionFirst actionIf it still fails
interrupted/partial writeClean up only incomplete artifacts proven to be run-owned
Fail
; report the unsafe cleanup path and restart condition
server/harness failurePreserve the command, exit state, output, and fake/real boundary
Fail
; do not expand into production/dependency scope
Execution succeeds but output/screenshot evidence is unavailableRetry capture once within the same boundary
Unverifiable
; do not claim 
Pass
ownership/state conflict with existing artifactPreserve the existing path and record evidence
Blocked
; choose another path before writing
cleanup failureRe-identify only run-owned resources and report the outcome`Fail
Scope expands to production/promotion/commitStop the prototype and separate it into another implementation request
Blocked
; do not auto-promote
在写入前记录预先存在的临时路径和运行生成的文件。
条件首要操作若仍失败
中断/部分写入仅清理经确认属于运行生成的不完整制品
Fail
；报告不安全的清理路径和重启条件
服务器/测试框架失败保留命令、退出状态、输出以及模拟/真实边界
Fail
；不要扩展到生产/依赖范围
执行成功但输出/截图证据不可用在同一边界内重试捕获一次
Unverifiable
；不要声称
Pass
与现有制品存在归属/状态冲突保留现有路径并记录证据
Blocked
；写入前选择其他路径
清理失败重新识别仅属于运行生成的资源并报告结果`Fail
范围扩展到生产/推广/提交停止原型制作，将其拆分为另一个实现请求
Blocked
；不要自动推广

🔴 CHECKPOINT · 🛑 STOP · Execution Boundary

🔴 检查点 · 🛑 停止 · 执行边界

Before execution, confirm the temporary path, fake/real data, and verification question. If environment or production-scope expansion occurs, stop at 
Blocked | Unverifiable
.
Before reporting, reconcile the command, actual output/screenshot, fake/real boundary, and unverified scope. If any are missing or execution failed, the result cannot be 
Pass
. Use 
Fail | Blocked | Unverifiable
.
执行前，确认临时路径、模拟/真实数据以及验证问题。 若出现环境或生产范围扩展的情况，标记为
Blocked | Unverifiable
并停止。
报告前，核对命令、实际输出/截图、模拟/真实边界以及未验证范围。若任何项缺失或执行失败，结果不能标记为
Pass
。 请使用
Fail | Blocked | Unverifiable
。

Contract

合约

Record decision-relevant status only once in its owning section. Start with 
## Confirmed
, followed by 
## Production implication
, 
## Tested
, 
## Variants or harness
, and 
## Still fake
, omitting empty sections. 
Confirmed
owns evidence-backed conclusions; 
Production implication
owns discard/iterate/next decision; 
Tested
owns command results; 
Variants or harness
owns alternatives/paths/run URLs and final 
kept | removed
state; and 
Still fake
owns fake/real and unverified scope. Place command mechanics after the decision.
Use exactly one terminal status: 
Pass | Fail | Blocked | Unverifiable
.
When comparing multiple criteria or variants, render 
## Confirmed
as a concise 
Criterion | A | B [| C] | Conclusion | Evidence
table. Use a sentence when there is only one user-relevant row. Record whether content/data/state remained identical. Use 
not observed
for differences that were not observed and 
unverifiable
when evidence is absent. Do not elevate unaudited aesthetic preferences into conclusions. Summarize the result and selection rationale in 2–5 bullets or option rows. If there are 8 or more observations, show the top 5–7 and cite the prototype or evidence path that owns the rest. This is a budget, not a quota.
仅在所属部分记录一次与决策相关的状态。以
## Confirmed
开头，随后是
## Production implication
、
## Tested
、
## Variants or harness
和
## Still fake
，省略空部分。
Confirmed
部分记录有证据支持的结论；
Production implication
部分记录丢弃/迭代/下一步决策；
Tested
部分记录命令结果；
## Variants or harness
部分记录替代方案/路径/运行URL以及最终
kept | removed
状态；
Still fake
部分记录模拟/真实状态和未验证范围。将命令机制放在决策内容之后。
仅使用以下一种终端状态：
Pass | Fail | Blocked | Unverifiable
。
当对比多个标准或变体时，将
## Confirmed
部分渲染为简洁的
Criterion | A | B [| C] | Conclusion | Evidence
表格。若仅有一行与用户相关的内容，则使用句子形式。记录内容/数据/状态是否保持一致。对于未观察到的差异，使用
not observed
；当证据缺失时，使用
unverifiable
。请勿将未经审核的审美偏好提升为结论。用2–5个项目符号或选项行总结结果和选择理由。若有8个或更多观察结果，显示前5–7个，并引用原型或证据路径来记录其余内容。这是预算限制，而非配额要求。

Prohibited Patterns

禁止模式

  • Do not call a prototype production-ready, auto-promote/commit it, or invoke another user skill.
  • Do not report fake integration as real or claim success without run evidence.
  • Do not add color-only variants, dependencies, manifest/lockfile edits, unnecessary production abstractions, or a third option with no value.
  • 请勿称原型为生产就绪，不要自动推广/提交它，也不要调用其他用户技能。
  • 请勿将模拟集成报告为真实集成，或在无运行证据的情况下声称成功。
  • 请勿仅添加颜色变体、依赖项、清单/锁文件编辑、不必要的生产抽象，或无价值的第三个选项。