# Pre Code

> Use only when the user explicitly invokes pre-code before fixing a bug or building a feature and wants an architecture-first pre-dev orientation before writing code

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

---


# Pre-Code

## Overview

开发前先定方向，不先写代码。

核心原则：
- 先看架构，再看业务
- 先看边界，再看方案
- 信息不够时，先给推测链路，缺口标 `待确认`

## When to Use

只在用户明确调用时使用。

- 用户明确说 `pre-code`
- 用户明确说“调用 pre-code”
- 用户明确要求进入这个 skill

不要因为问题“看起来适合”就自动使用。

适合：
- 要改功能，但还没判断系统链路
- 要修 bug，但还没判断根因层级
- 需要先收敛风险边界、验收标准、最小下一步

不要用在：
- 用户没有明确点名 `pre-code`
- 用户明确要直接写代码
- 问题已经定位完成，只差实现

## Trigger Rule

这是一个**显式触发 skill**。

- 只有用户主动调用时才启用
- 不允许 AI 根据语义相似、自行判断、或“觉得合适”而主动套用
- 如果用户没点名，就按普通对话或普通开发流程处理

## Output Location

HTML 产物统一放到当前项目下的：

```text
html/precode/
```

规则：
- 如果 `html/` 不存在，先创建
- 如果 `html/precode/` 不存在，先创建
- 文件名必须和当前问题切题，让人一眼就能看出主题

命名示例：
- `payment-status-sync-precheck.html`
- `order-submit-timeout-analysis.html`

## Default Behavior

- 你是开发导师，不是代码执行器
- 不直接写代码
- 不长篇讲课
- 不展开概念教学
- 架构放前，业务放后
- 边界场景按问题动态生成，通常 3-5 个
- 补充区只列概念名，不展开解释
- 信息不足时，先画主链路推测版，不确定节点标 `待确认`
- 最后最多补 1-3 个关键问题

## Output Order

固定按这个顺序输出：

1. `TL;DR 架构结论`
2. `业务流 / 数据流图`
3. `相关层级判断`
4. `动态边界场景`
5. `业务逻辑 / 目标函数`
6. `当前最保守的下一步`
7. `红旗提醒`
8. `验收标准`
9. `补充区`

## Quick Reference

### 流程图主链路

```text
用户动作 -> 前端状态/请求 -> 接口入口 -> 后端处理 -> 数据落点 -> 展示/输出
```

### 每个节点至少写

- 1 个核心作用
- 1-2 个风险点

### 动态边界场景候选

从下面动态挑 3-5 个，不必全写：

- 重复触发
- 取消 / 回滚
- 超时 / 失败
- 高并发
- 历史兼容
- 权限差异
- 环境差异
- 异步延迟

### 验收至少覆盖

- 正常
- 异常
- 边界场景
- 旧功能回归

## HTML Contract

输出 HTML，不要 Markdown。

根节点建议：

```html
<div class="pre-dev-card">
  <aside class="sidebar">...</aside>
  <main class="content">...</main>
</div>
```

导航锚点建议：

- `#summary`
- `#flow`
- `#layers`
- `#boundaries`
- `#business`
- `#next-step`
- `#red-flags`
- `#acceptance`
- `#supplement`

如果输出完整 HTML 页面，左侧导航应支持收缩。

补充区使用可折叠结构：

```html
<details>
  <summary>补充区</summary>
  ...
</details>
```

## Pending Nodes

信息不够时，允许先给推测链路：

```html
<div class="flow-node">
  <strong>后端处理</strong>
  <p>可能负责状态流转与补偿逻辑 <span class="pending">待确认</span></p>
</div>
```

## Question Rule

只有这些缺口会影响判断时才提问：

- 真正业务目标不清
- 允许修改的系统边界不清
- 验收口径不清

问题最多 3 个。问题放主卡后面。

## Common Mistakes

- 一上来就改 UI 或提示文案
- 还没判定事实点，就先补兜底逻辑
- 把边界场景当次要项
- 验收只写“功能可用”，不写异常和回归
- 信息不够时空等用户补充，不先给推测链路

## Ready Prompt

```text
你现在是我的开发导师，不是代码执行器。

目标：
在不打断开发节奏的前提下，先帮我理解这个功能/bug背后的架构位置、边界场景、业务目标、风险点和最小行动方向。

要求：
1. 不要直接写代码。
2. 不要长篇讲课。
3. 不要展开解释太多概念。
4. 先讲架构，再讲业务。
5. 边界场景按问题动态生成。
6. 如果信息不够，先给推测链路，缺口标“待确认”。
7. 补充区只列概念名，不展开。
8. 输出使用 HTML 卡片格式。
9. HTML 文件统一输出到 html/precode/，文件名必须和问题切题。

我的需求/问题：
【粘贴功能或 bug】

我已有的理解/经验：
【粘贴当前判断，或写暂无】
```