properize

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Properize

规范化（Properize）

Turn "I hacked this together for myself, it's AI slop, but I want it proper now" into a repo that meets lgtm-hq standards. This skill sequences other skills into one pipeline — it composes

commit

, design grilling,

issue

, and

implement-issues

pr

, it does not replace them. Never skip a stage or collapse two stages into one session; each stage produces an artifact (commits, a design decision, an issue tree) the next stage depends on.

把“我自己凑出来的这个东西就是AI草稿，但现在我想让它变得规范”的仓库升级为符合lgtm-hq标准的项目。该Skill会将其他Skill编排成一条流水线——它整合了

commit

、设计审查、

issue

以及

implement-issues

pr

等Skill，而非替代它们。绝不要跳过任何阶段或将两个阶段合并为一次操作；每个阶段都会产出下一个阶段依赖的成果（提交记录、设计决策、任务层级结构）。

The mistake this skill prevents

该Skill避免的误区

The default failure mode is jumping straight from "make this proper" to writing a full implementation plan and executing it in one pass — no commit checkpoint, no design interrogation, no issue trail. That produces an unreviewable mega-diff and bakes in whatever the prototype already got wrong. Do NOT do this. Do: commit → grill → recon → spec → implement, one stage at a time, stopping between stages for the artifacts to exist and be reviewable.

常见的错误模式是直接从“让这个项目规范化”跳到编写完整的实现计划并一次性执行——没有提交 checkpoint、没有设计质询、没有任务追踪记录。这会产生无法评审的巨型代码差异，并且会把原型中已存在的问题固化下来。绝对不要这么做。正确的流程是：提交 → 审查 → 调研 → 梳理 → 实现，分阶段逐步进行，每个阶段结束后需确保产出的成果可被评审，再进入下一阶段。

Pipeline

流水线

1. Commit the WIP first

1. 先提交WIP

Before any design discussion, get the current state to a lint-clean, committed baseline:

Drive
```
uv run lintro chk
```
to 0 issues. Fix real bugs the gate surfaces (missing imports, undefined names, missing arguments, type errors, dead-code/unused-variable warnings) rather than suppressing them — a lint gate on a prototype routinely finds actual bugs, not just style nits.
Land signed, semantic commits grouped by domain, not one giant commit. For example: a
```
cleanup
```
pass, then commits per feature area (e.g.
```
discover
```
,
```
playlists
```
), then
```
app-infra
```
, then a trailing
```
chore
```
for anything left over. Follow the
```
commit
```
skill for message format and signing.
Do not refactor or redesign here — only make the WIP lint-clean and historied. Design changes belong in the next stage.

在进行任何设计讨论之前，先将当前状态转化为经过lint校验的提交基线：

运行
```
uv run lintro chk
```
直至问题数为0。修复校验工具发现的真实bug（缺失的导入、未定义的变量、缺失的参数、类型错误、死代码/未使用变量警告），而非忽略它们——原型的lint校验通常会发现实际bug，而非仅仅是风格问题。
提交经过签名的语义化提交，按领域分组，而非一个巨型提交。例如：先做一次
```
cleanup
```
提交，然后按功能模块提交（如
```
discover
```
、
```
playlists
```
），接着是
```
app-infra
```
，最后用
```
chore
```
提交处理剩余的杂项。提交信息格式和签名需遵循
```
commit
```
Skill的要求。
此阶段不要进行重构或重新设计——仅需让WIP通过lint校验并生成提交历史。设计变更属于下一阶段。

2. Grill the design

2. 审查设计

Stress-test the full design before writing any spec. Prefer the external

grilling

skill when it is installed (e.g. mattpocock/grilling via the vendor catalog); otherwise run the same interview inline. One question at a time, waiting for an answer before the next — do not batch questions. Recommend an answer with each question. Cover at least:

Audience and multi-tenancy (single-user tool vs. shared service?)
Data storage (what DB, migrations, backups?)
Auth (who can access it, how?)
Background jobs / scheduling
Configuration and secrets management
Deployment target and process
Documentation expectations (README, ADRs?)
Scope freeze — what's explicitly out of scope for v1
Observability (logging, metrics, error tracking)
Testing strategy and coverage bar
Issue granularity for the next stage (how small is "one PR"?)

Do not proceed to standards recon until these questions have answers. If the user defers a question, record the deferral explicitly rather than assuming a default.

在编写任何规范之前，对完整设计进行压力测试。如果已安装外部

grilling

Skill（例如供应商目录中的mattpocock/grilling），优先使用该Skill；否则可在本地执行相同的质询流程。一次只问一个问题，得到答案后再问下一个——不要批量提问。每个问题需给出推荐答案。至少覆盖以下内容：

受众与多租户（单用户工具还是共享服务？）
数据存储（使用什么数据库、迁移方案、备份策略？）
认证（谁可以访问，如何访问？）
后台任务/调度
配置与密钥管理
部署目标与流程
文档要求（README、ADR？）
范围冻结——v1版本明确排除的内容
可观测性（日志、指标、错误追踪）
测试策略与覆盖率标准
下一阶段的任务粒度（“一个PR”的规模有多小？）

在得到这些问题的答案之前，不要进入标准调研阶段。如果用户推迟某个问题的回答，需明确记录推迟情况，而非默认采用某种方案。

3. Standards recon (before writing issues)

3. 标准调研（编写任务之前）

Run this recon after grilling and before stage 4 so branch rulesets and CI requirements shape the backlog. Treat it as a checklist of repeatable commands, not a judgment call:

Fetch
```
winnow
```
workflows as the gold-standard CI reference (full workflow set).
Fetch
```
lgtm-ci
```
reusable workflows pinned to a release SHA (plus the tooling-ref pin), not a floating tag.
Fetch the org's rulesets for the target repo (
```
checks-<repo>
```
) via
```
gh api repos/<owner>/<repo>/rulesets
```
(or the org-level ruleset endpoint) so branch-protection requirements are known before issues are written.
Bring in the standard community-files set:
```
.editorconfig
```
,
```
SECURITY.md
```
, Renovate config, gitleaks config, and equivalents already used across lgtm-hq repos.
Make
```
lintro
```
the sole lint/format entry point — no bare
```
ruff
```
/
```
eslint
```
/ etc. invocations left in scripts or CI.
Wire releases through the version-PR + auto-tag flow used elsewhere in lgtm-hq, not manual tagging.

Do not create milestones, epics, or issues until this recon is complete.

在审查设计之后、第4阶段之前执行此调研，以便分支规则集和CI要求能指导待办事项的梳理。将其视为可重复执行的命令清单，而非主观判断：

获取
```
winnow
```
工作流作为CI的黄金标准参考（完整工作流集合）。
获取固定到发布SHA的
```
lgtm-ci
```
可复用工作流（加上工具引用的固定版本），而非浮动标签。
通过
```
gh api repos/<owner>/<repo>/rulesets
```
（或组织级规则集端点）获取目标仓库的组织规则集（
```
checks-<repo>
```
），以便在编写任务前了解分支保护要求。
引入标准社区文件集：
```
.editorconfig
```
、
```
SECURITY.md
```
、Renovate配置、gitleaks配置，以及lgtm-hq仓库中已使用的等效文件。
将
```
lintro
```
作为唯一的lint/格式化入口——脚本或CI中不要保留裸调用的
```
ruff
```
/
```
eslint
```
等工具。
通过lgtm-hq其他仓库使用的版本PR + 自动标签流程来管理发布，而非手动打标签。

在完成此调研之前，不要创建里程碑、史诗或任务。

4. Spec the backlog as milestones, epics, and issues

4. 将待办事项梳理为里程碑、史诗和任务

Turn the grilled design into a milestone → epic → issue tree:

Milestones group epics by release/phase.
Epics group issues by feature area.
Issues are one-PR-sized. Every code issue gets an AI Implementation Prompt comment in the
```
issue
```
skill's format (see
```
skills/issue/SKILL.md
```
), so any issue is fan-out-ready for
```
implement-issues
```
without rework.
Generalize the issue-generation script pattern (Python +
```
gh
```
calls creating milestones, epics, and issues from a structured spec) into a repo-agnostic template rather than a one-off script tied to this repo's domain. Keep the domain content (titles, bodies, prompts) separate from the generation mechanics so the template is reusable on the next prototype.

把经过审查的设计转化为里程碑 → 史诗 → 任务的层级结构：

里程碑：按发布/阶段对史诗进行分组。
史诗：按功能模块对任务进行分组。
任务：规模对应一个PR。每个代码任务都需在
```
issue
```
Skill规定的格式下添加AI实现提示注释（参见
```
skills/issue/SKILL.md
```
），以便任何任务都能直接交给
```
implement-issues
```
执行，无需返工。
将任务生成脚本模式（Python +
```
gh
```
调用，从结构化规范创建里程碑、史诗和任务）抽象为仓库无关的模板，而非绑定到当前仓库领域的一次性脚本。将领域内容（标题、描述、提示）与生成逻辑分离，以便该模板可复用至下一个原型项目。

5. Implement, issue by issue

5. 逐个任务实现

Only after the tree exists: implement issues one at a time, small PRs, per the

pr

skill (or hand the whole ready backlog to

implement-issues

for parallel, worktree-isolated lanes). Never batch unrelated issues into one PR to save time — the point of stage 4 was to make each unit reviewable on its own.

仅在任务层级结构生成后，逐个实现任务，提交小型PR，遵循

pr

Skill的要求（或把整个就绪的待办事项交给

implement-issues

以并行、工作树隔离的方式执行）。绝不要为了节省时间将无关任务批量合并到一个PR中——第4阶段的目的就是让每个任务单元都能独立评审。

Guardrails

约束规则

Stage order is not negotiable. Do not run standards recon before the design has been grilled, do not spec issues before recon is done, and do not implement before the issue tree exists.
Stop between stages. Each stage's artifact (commit history, recorded design decisions, recon notes, the issue tree) should be reviewable before the next stage starts — do not silently chain all five stages into one unattended run.
A stage that cannot stay green (lint, tests, or an unanswered blocking design question) stops and reports rather than pushing through.
This skill never merges — implementation PRs follow the normal review and merge process for the target repo.

阶段顺序不可协商。不要在设计审查完成前进行标准调研，不要在调研完成前梳理任务，不要在任务层级结构生成前开始实现。
阶段间需停顿。每个阶段的成果（提交历史、记录的设计决策、调研笔记、任务层级结构）需在进入下一阶段前可被评审——不要将五个阶段静默串联为一次无人值守的运行。
如果某个阶段无法保持正常状态（lint、测试不通过，或存在未解决的阻塞性设计问题），需停止并报告，而非强行推进。
该Skill从不执行合并操作——实现PR需遵循目标仓库正常的评审与合并流程。