Back to Details

antislop-codebase

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Antislop Codebase

Antislop 代码库

Use this skill to move a repo from "works but hurts" to a product-shaped cluster of small, typed, tested, maintainable modules while keeping the current product essentially as-is. Treat this as the first maintainability/productization pass, not the broader production-readiness program.
使用此技能可将代码仓库从“能运行但维护痛苦”的状态转变为由小型、带类型、经过测试、易于维护的模块组成的产品级结构，同时基本保持当前产品的原有功能。将此视为首次可维护性/产品化改造，而非更广泛的生产就绪计划。

Boundary

边界范围

This skill is for structural maintainability: code organization, typed boundaries, tests, feature folders, API consolidation, file-size reduction, styling cleanup, and audit evidence.
Do not expand the scope into a full production-readiness initiative. Observability/logging programs, security reviews, compliance, incident response, SLOs, runbooks, secrets posture, penetration testing, and deep reliability engineering belong in separate follow-on skills unless the user explicitly asks to include a small enabling change.
此技能专注于结构可维护性：代码组织、类型边界、测试、功能文件夹、API整合、文件大小缩减、样式清理以及审计证据。
请勿将范围扩展为完整的生产就绪计划。可观测性/日志程序、安全审查、合规性、事件响应、SLO、运行手册、密钥状态、渗透测试和深度可靠性工程属于后续独立技能的范畴，除非用户明确要求纳入少量支持性变更。

Operating Principles

操作原则

  • Preserve behavior first. Improve architecture in thin, reversible slices.
  • Ground every decision in repo facts: file sizes, dependency graph, tests, runtime shape, API surfaces, user workflows, deployment limits, and current dirty worktree.
  • Keep files AI-editable: prefer focused modules under roughly 300-500 lines, explicit feature folders, stable compatibility barrels, and narrow tests.
  • Never rewrite active user-owned areas without permission. If other agents/users are editing a surface, audit or work around it.
  • Use concurrent subagents for independent analysis or isolated edit slices when available, but merge with one owner who validates the whole tree.
  • Commit at green checkpoints. Do not let a migration become a giant unreviewable diff.
  • End with evidence: a migration audit microsite served locally, with visuals, metrics, risks, and before/after interpretation.
  • 首先保留功能。以可回滚的小增量方式改进架构。
  • 所有决策均基于代码库实际情况：文件大小、依赖图、测试、运行时形态、API接口、用户工作流、部署限制以及当前未提交的修改内容。
  • 保持文件可被AI编辑：优先采用约300-500行以内的聚焦模块、明确的功能文件夹、稳定的兼容入口文件（barrels）和针对性测试。
  • 未经许可，切勿重写用户正在编辑的区域。如果其他Agent/用户正在编辑某一代码面，需进行审计或绕开处理。
  • 若可用，使用并发子Agent进行独立分析或孤立的代码片段编辑，但需由一位负责人合并并验证整个代码树。
  • 在测试通过的检查点提交代码。切勿让迁移变成无法评审的巨大差异文件。
  • 最终提供证据：本地部署的迁移审计微网站，包含可视化内容、指标、风险以及前后对比解读。

Workflow

工作流程

1. Establish The Product Shape

1. 确定产品级结构

Run a quick non-mutating discovery pass before planning:
  • Find package scripts, app entrypoints, API routes, deployment config, test harnesses, type config, and current git status.
  • Measure largest files and top directories.
  • Identify user-critical workflows, deployment constraints, data persistence, auth, provider integrations, and expensive operations only insofar as they affect safe refactoring.
  • Read recent commits and docs to avoid undoing active work.
If the repo is live or user-facing, default to compatibility-preserving migrations and rollback paths.
For deeper discovery prompts and commands, see analysis-checklist.md.
在规划前先执行快速的非破坏性发现流程：
  • 查找包脚本、应用入口、API路由、部署配置、测试工具、类型配置以及当前git状态。
  • 测量最大文件和顶级目录的大小。
  • 识别对用户至关重要的工作流、部署约束、数据持久化、认证、供应商集成以及昂贵操作，但仅关注那些会影响安全重构的部分。
  • 阅读近期提交记录和文档，避免撤销正在进行的工作。
如果代码库是在线或面向用户的，默认采用兼容型迁移并提供回滚路径。
如需更深入的发现提示和命令，请查看analysis-checklist.md。

2. Write A Decision-Complete Migration Plan

2. 编写可执行的完整迁移计划

Produce a plan that can evolve, but is complete enough for another agent to execute:
  • Goal, success criteria, explicit non-goals, active no-touch areas, and risk posture.
  • Staged slices ordered by blast radius and verification confidence.
  • Public interfaces and compatibility promises.
  • Test plan: current baseline, new tests needed, e2e/visual checks, deploy smokes.
  • Concurrency map: which workers can edit independently and which files are single-owner.
  • Checkpoint policy: when to commit, push, deploy, and audit.
Use 
request_user_input
only for product tradeoffs that cannot be discovered from the repo.
生成一份可演进但足够完整的计划，确保其他Agent也能执行：
  • 目标、成功标准、明确的非目标、不可触碰的活跃区域以及风险态势。
  • 按影响范围和验证可信度排序的分阶段改造片段。
  • 公共接口和兼容性承诺。
  • 测试计划：当前基准、所需新增测试、端到端/视觉检查、部署冒烟测试。
  • 并发映射：哪些工作可独立编辑，哪些文件需单一负责人。
  • 检查点策略：何时提交、推送、部署和审计。
仅在无法从代码库中发现产品权衡决策时，使用
request_user_input
请求用户输入。

3. Build The Baseline Safety Net

3. 构建基准安全网

Before broad edits:
  • Run existing typecheck, unit tests, build, and e2e if practical.
  • If tests are missing, add or plan the smallest high-value characterization tests before refactoring behavior.
  • Add only minimal diagnostics or recoverable error handling needed to make the refactor safe; defer comprehensive logging/observability programs to a separate production-readiness skill.
  • Capture screenshots for core UX surfaces; for browser e2e, visually inspect mobile, desktop, tablet, and ultrawide output when practical.
在进行广泛编辑前：
  • 尽可能运行现有的类型检查、单元测试、构建和端到端测试。
  • 如果缺少测试，在重构功能前添加或规划最小化的高价值特征测试。
  • 仅添加使重构安全所需的最小诊断或可恢复错误处理；将全面的日志/可观测性程序推迟到独立的生产就绪技能中处理。
  • 捕获核心用户界面的截图；对于浏览器端到端测试，尽可能视觉检查移动端、桌面端、平板和超宽屏的输出。

4. Execute In Green Slices

4. 分阶段执行（测试通过后）

Process the migration methodically:
  • Split largest and hottest files first, preserving old import surfaces through barrels/facades.
  • Extract pure models/helpers before UI shells.
  • Convert untyped or ad hoc boundaries to shared domain types and runtime validation where API/provider data crosses a trust boundary.
  • Consolidate duplicated server/API functions only after response shapes are pinned by tests.
  • Migrate styling surface-by-surface; remove legacy selectors only after screenshot checks.
  • Keep each slice small enough to test, review, and revert.
Use up to the user-approved subagent concurrency. Assign workers to independent surfaces such as tests, CSS, server helpers, frontend feature extraction, type boundaries, and audit tooling. Do not let subagents edit the same hot files concurrently.
For execution rules and worker prompts, see execution-playbook.md.
有条不紊地执行迁移：
  • 首先拆分最大和最热门的文件，通过入口文件（barrels）/ facade保留旧的导入接口。
  • 在提取UI外壳之前，先提取纯模型/辅助函数。
  • 在API/供应商数据跨越信任边界时，将无类型或临时边界转换为共享领域类型和运行时验证。
  • 仅在测试固定响应形态后，合并重复的服务器/API函数。
  • 逐个迁移样式面；仅在截图检查通过后移除旧选择器。
  • 保持每个片段足够小，以便测试、评审和回滚。
使用用户批准的子Agent并发数。将工作分配到独立的代码面，如测试、CSS、服务器辅助函数、前端功能提取、类型边界和审计工具。禁止子Agent同时编辑相同的热门文件。
如需执行规则和工作提示，请查看execution-playbook.md。

5. Validate, Commit, Deploy

5. 验证、提交、部署

At each checkpoint:
  • Run the narrow tests for the touched surface.
  • Run broader typecheck/build/unit tests before committing.
  • Run e2e/visual smoke before deploy when UI or production flows changed.
  • Commit only the intended files; preserve unrelated dirty user work.
  • Deploy only when the agreed release gate is green, or explicitly mark a known-risk release.
在每个检查点：
  • 运行受影响代码面的针对性测试。
  • 提交前运行更广泛的类型检查/构建/单元测试。
  • 当用户界面或生产流程变更时，部署前运行端到端/视觉冒烟测试。
  • 仅提交目标文件；保留用户未提交的无关修改。
  • 仅在约定的发布闸门测试通过时部署，或明确标记已知风险的发布。

6. Finish With A Migration Audit Microsite

6. 生成迁移审计微网站

When the migration is stable, generate a static HTML audit microsite that answers:
  • Did maintainability improve?
  • How many LOC/files were added/removed?
  • Which file sizes collapsed?
  • How did the structure evolve?
  • What changed in tests, types, API functions, deployment risk, and UX coverage?
  • What costs and risks remain?
Serve the microsite locally and return a clickable 
localhost
or 
127.0.0.1
URL. The user prefers opening microsite artifacts inside Codex rather than receiving only a file path.
Use audit-microsite.md for metrics, structure, and validation.
当迁移稳定后，生成静态HTML审计微网站，回答以下问题：
  • 可维护性是否有所提升？
  • 新增/移除了多少代码行数/文件？
  • 哪些文件大小被缩减？
  • 架构如何演变？
  • 测试、类型、API函数、部署风险和用户覆盖范围有哪些变化？
  • 仍存在哪些成本和风险？
在本地部署该微网站，并返回可点击的
localhost
或
127.0.0.1
URL。用户更倾向于在Codex内打开微网站工件，而非仅接收文件路径。
如需指标、结构和验证方法，请查看audit-microsite.md。

Quality Bar

质量标准

A successful antislop migration has:
  • No giant ownership-free files in hot paths.
  • Clear feature/provider/domain folders.
  • Typed module boundaries for frontend/backend/API/provider data.
  • Tests that carry their weight and can be run narrowly.
  • Production-shaped local/dev deploy checks.
  • A final audit artifact that is honest about wins, costs, and residual risks.
成功的Antislop迁移需满足：
  • 热门路径中无无人负责的巨型文件。
  • 清晰的功能/供应商/领域文件夹结构。
  • 前端/后端/API/供应商数据的类型化模块边界。
  • 高效且可针对性运行的测试。
  • 产品级的本地/开发环境部署检查。
  • 一份诚实展示成果、成本和剩余风险的最终审计工件。