Skip to main content

architect

Design production modules, interfaces, seams, types, signatures, and dependency structure before implementation. Use ONLY when the requested result is a production code shape or integration contract, such as 'architect this' or 'design this module'. Do not use for throwaway HTML experiments that test state, transition, policy, scheduling, or algorithm behavior.

ソース情報

リポジトリ
davesnx/setup
ソースの最終更新活動
2026年9月17日 18:50
検出された SKILL.md の言語
英語
スター
11
フォーク
1

インストール方法

デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。

ソースファイルを確認

インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。

ファイルエクスプローラー
8 ファイル

SKILL.md を表示中

SKILL.md
ソースの指示 · 読み取り専用プレビュー
name
architect
description
Design production modules, interfaces, seams, types, signatures, and dependency structure before implementation. Use ONLY when the requested result is a production code shape or integration contract, such as 'architect this' or 'design this module'. Do not use for throwaway HTML experiments that test state, transition, policy, scheduling, or algorithm behavior.
# Architect Design the production contract before implementation. Sketch caller usage, types, function signatures, module boundaries, seams, and dependency direction with `not implemented` bodies or brief pseudocode where needed. Synthesize across multiple model perspectives, then hand the chosen design to the implementation workflow. ## Boundary - Architect owns production module and interface design that code will implement. - Logic Prototype owns disposable, drivable HTML used to learn whether logic works. Route by the requested deliverable, not by the subject. A production state-machine interface belongs here; an interactive state-machine experiment does not. - Architect ends with a design package. Do not write production implementation as part of this skill. ## Start Open a todolist with one entry per phase before starting. Autonomous mode without checkpoints needs the list to show phase position and keep phases from silently disappearing. 1. Ground 2. Explore and synthesize 3. Deliver and hand off ## Phase A: Ground the problem Build a real mental model of every system the new code touches. Trace the relevant entry points, data flow, ownership, boundaries, and callers directly. Critique the current structure when it constrains the design. Read `references/codebase-design.md` and use its module, interface, depth, seam, adapter, leverage, and locality vocabulary throughout. For dependency-heavy restructuring, also read `references/deepening.md`. Naming a file isn't grounding. Produce a traced model of the relevant subsystem. If the design redefines ownership or layering, inspect commit history, architecture docs, and nearby decisions so the existing rationale becomes a constraint, not a guess. Skip Phase A only when the work is genuinely greenfield with no surrounding system to integrate. ## Phase B: Explore and synthesize Launch one read-only design runner per available configured model in parallel. Give every runner the Phase A grounding artifacts, `references/codebase-design.md`, and `references/runner-prompt.md`. Each candidate produces a design package shaped per `references/rationale-template.md`: the caller's usage written first, then the type sketch, function signatures, module map, and prose rationale derived from it. Use `references/design-it-twice.md` when the interface needs deliberately different shapes rather than variations of one design. If model selection is unavailable, use independent runners and state that the candidates do not prove model diversity. Explore whole-shape alternatives, not point fixes inside one shape. Compare the candidates, select the strongest package as the base, and graft in compatible strengths from the others. Record what was selected, adapted, and rejected in the rationale's "Synthesis decision" section. ## Phase C: Deliver and hand off Present the synthesized design as the final Architect result. Include the caller's usage, type and signature sketch, module map, seam and adapter choices, invariants, tradeoffs, rejected alternatives, open questions, and the first implementation step. Do not edit production source files or fill in the sketched bodies. If the user also requested implementation, make the completed design the input to the normal implementation workflow. Changes discovered during later implementation are new evidence and can trigger another Architect pass. Once required design decisions are settled, recommend `/implement` with the completed design and agreed scope. If the human rejects the shape, treat that response as Phase A evidence, re-ground, and run Phase B again. For adversarial pressure before handoff, run an adversarial review of the synthesized sketch where the harness offers one (in OpenCode, the code-review skill's Adversarial mode). ## Outputs The caller's usage is written first and the type sketch derived from it. One file with new types and signatures for small changes; module map plus type definitions for larger work. The rationale ships alongside, shaped per `references/rationale-template.md`, including the usage sketch and the synthesis decision.
GitHubで見る