Framework Development 是 agentic-qa-boilerplate 仓库中用于演进 QA 框架自身的技能（skill），属于框架架构层面的改动入口。它管理 KATA 分层、fixtures、安装器、OpenAPI 管线、脚本与 doctrine 文档等框架表面的变更。
用途 该技能用于对框架本身进行改动，例如新增 fixture、新增层辅助函数、重写安装器、修改 manifest 提取器等。它强调框架表面的改动应在写代码之前经过规划门禁。按工单的测试编写、手工 QA、TMS 文档、套件运行分别由 /test-automation、/sprint-testing、/test-documentation、/regression-testing 负责，不应触发本技能。
主要能力与规则 技能包含一组紧凑规则：不得将本技能用于按工单的工作；应先通过就绪预检，再依据 references/kata-invariants.md §10 运行 Phase 0 路径自检，遇到 FORBIDDEN 路径会中止并重定向到对应技能，未列出的路径会询问而非假设。当一次改动同时涉及 ALLOWED 与 FORBIDDEN 路径时应拆分：本技能改基础，/test-automation 在后续迁移消费方规格。每个非平凡框架改动都须按 Plan → Code → Verify → Archive 顺序执行。不得在框架开发会话中编辑按工单测试；KATA 基础（TestContext.ts、ApiBase.ts、UiBase.ts）与 fixture 文件属于本技能范围。不得以简化理由合并 KATA 分层。新增 fixture API 须同步更新对应 fixture 文件、kata-manifest.json，并引用至少一个现有消费测试。不得在没有代表性 E2E 套件回归运行的情况下升级 Playwright / Bun / TypeScript 主版本。不得在未于干净克隆上完整演练安装流程的情况下重构 cli/install.ts。当所选方案重塑测试架构且难以逆转时，应在计划批准后、编码前于 .context/ADR/ 记录 ADR。验证须通过 test、types、lint、skills 四项检查，任何非零退出视为 REJECT，并呈现重试 / 跳过并记录 / 中止，不得自动修复。当改动本身是技能时，按 skill-scaffold.md 脚手架，skill-creator 始终作为构建器。子代理不得写 progress.md，该文件仅由编排器维护。新增、重命名或退役技能、package.json 脚本或文档路径，或改变页面描述的行为时，须在同一 PR 完成文档跟进。当编辑落在 LINT.IfChange 区域时，须在同一推送更新其 LINT.ThenChange 指定的每个页面。当改动触及 cli/、scripts/、.husky/、AGENTS.md 或 .agents/instructions/ 时，在四项验证器后运行 V5 漂移扫描（仅报告）。仅在四项验证器全部通过后归档会话目录。对 AGENTS.md、.agents/instructions/ 下章节、ROUTER 或 triggers 列表的改动须走 instructions 模式。当触发词漏触发或过度触发时，修复章节的 triggers 并添加提示到 cli/lib/fixtures/instruction-router-eval.json。
使用方式 技能通过模式路由：$ARGUMENTS 第一个词若命名了模式即为该模式，否则运行默认管线。默认模式触发短语包括 evolve framework、new fixture API、refactor cli、boilerplate evolution、sync AI context，输出为经过验证的框架改动。instructions 模式触发短语包括 edit AGENTS.md、add a rule、where does this rule go、router row、tune the triggers、new instruction section，输出为编辑后的指令文件与通过的 instructions:check。
流程与阶段 技能采用四阶段：Phase 0 路径自检 + 会话恢复检查（内联，仅编排器）；Phase 1 计划（单个 Plan 子代理写 plan.md）；Phase 2 编码（按任务批次顺序，每个批次一个 Code 子代理）；Phase 3 验证（并行子阶段运行 bun run test、bun run types:check、bun run lint:check、bun run skills:check，随后聚合决策，必要时运行 V5 漂移扫描）；Phase 4 归档（内联，移动会话目录）。会话状态位于 .session/framework-development/<change-name>/{plan.md, progress.md}。计划产物位于 .session/framework-development/<change-name>/plan.md，.session/ 树被 gitignore。
输入与阅读顺序 冷启动时的规范阅读顺序为：kata-manifest.json（组件与 ATC 注册表）、.agents/skills/test-automation/references/kata-architecture.md 与 typescript-patterns.md、tests/components/、cli/install.ts、scripts/sync-openapi.ts 与 api/schemas/、package.json 与 bun.lock。改动足够小时可提前停止。
子代理调度 编排与会话契约遵循 agentic-qa-core/references/orchestration-doctrine.md 与 session-management.md。每次调度遵循 7 组件简报格式，模式选择匹配 dispatch-patterns.md。Phase 0 与 Phase 1 非可选。路径护栏按调度注入：每个 Plan 与 Code 子代理简报必须包含 KATA 不变量与 ALLOWED/FORBIDDEN 路径引用行。子代理失败时停止，不自动重跑。Strict TDD 标志在 Phase 1 的 plan.md 中设置，默认 OFF。
Fleet seam（可选） Phase 2 编码默认按任务批次顺序执行。当计划批次真正独立时，可提供 wave 模式：多个持久 worker 会话各取一个任务批次，由 conductor 集成。拓扑为同一检出、按 worker 划分文件所有权，worker 提交时显式指定路径。conductor 始终写 launch.txt。Phase 0 与 Phase 3 保留给 conductor。
适用场景与限制 适用于框架架构层面的演进，如新增 fixture API、重构 cli、同步 AI 上下文、编辑指令文件等。不适用于按工单的测试编写、手工 QA、TMS 文档或回归运行。具体收费、价格、平台支持等信息暂未提供。