architecture-review
Use when reviewing a PR, branch, or staged diff in the openboot repo. Audits the change against project invariants from AGENTS.md — subprocess hygiene, HTTP wrapper usage, error wrapping, dry-run gating, UI helper usage, test placement. Trigger when user says "review this", "check this PR", "audit the diff", or asks about whether a change follows project conventions.
- License 许可
- MIT
- 最近更新
- 2026-11-03
- Stars
- ★ 278
- Forks
- 14
01 前言 Front Matter
- name
- architecture-review
- description
- Use when reviewing a PR, branch, or staged diff in the openboot repo. Audits the change against project invariants from AGENTS.md — subprocess hygiene, HTTP wrapper usage, error wrapping, dry-run gating, UI helper usage, test placement. Trigger when user says "review this", "check this PR", "audit the diff", or asks about whether a change follows project conventions.
02 资源文件 34
- 参考文档fixtures/agent-memory-types-style4.json4.5 KB
- 参考文档fixtures/api-flow-style7.json3.3 KB
- 参考文档fixtures/mem0-style1.json7.8 KB
- 参考文档fixtures/microservices-style3.json5.2 KB
- 参考文档fixtures/multi-agent-style5.json3.9 KB
- 参考文档references/diagram-catalog.md5.5 KB
- 参考文档references/icons.md14.6 KB
- 参考文档references/style-1-flat-icon.md3.2 KB
- 参考文档references/style-2-dark-terminal.md3.0 KB
- 参考文档references/style-3-blueprint.md3.3 KB
- 参考文档references/style-4-notion-clean.md2.8 KB
- 参考文档references/style-5-glassmorphism.md3.8 KB
- 参考文档references/style-6-claude-official.md6.9 KB
- 参考文档references/style-7-openai.md6.8 KB
- 参考文档references/style-8-dark-luxury.md7.7 KB
- 参考文档references/style-diagram-matrix.md7.6 KB
- 参考文档references/svg-authoring-and-recovery.md2.8 KB
- 参考文档references/svg-layout-best-practices.md3.8 KB
- 参考文档references/visual-vocabulary-and-layout.md3.5 KB
- 脚本scripts/generate-diagram.sh5.2 KB
- 脚本scripts/generate-from-template.py64.1 KB
- 脚本scripts/generate-svg-from-lines.py911 B
- 脚本scripts/test-all-styles.sh4.0 KB
- 脚本scripts/validate-svg.sh8.3 KB
- 资产文件templates/agent-architecture.svg1.3 KB
- 资产文件templates/architecture.svg1.0 KB
- 资产文件templates/comparison-matrix.svg612 B
- 资产文件templates/data-flow.svg1.3 KB
- 资产文件templates/er-diagram.svg1003 B
- 资产文件templates/flowchart.svg860 B
- 资产文件templates/sequence.svg856 B
- 资产文件templates/state-machine.svg846 B
- 资产文件templates/timeline.svg832 B
- 资产文件templates/use-case.svg947 B
03 SKILL.md 正文
Architecture review for openboot
Run this checklist on any diff before approving it. The checks map 1:1 to
the rules in AGENTS.md → "Project-specific conventions" and the
fitness functions in internal/archtest.
Step 1 — Diff scope
Confirm what's changed:
git diff --stat main...HEAD # files
git diff main...HEAD -- 'internal/**/*.go' # production Go
If the diff spans more than ~10 files or mixes feature + refactor + docs, call that out and suggest splitting — one thing per commit is a project convention.
Step 2 — Run the mechanical checks first
go vet ./...
make test-unit # includes archtest
golangci-lint run ./... # if available
These catch ~80% of what a human reviewer would otherwise comment on. If they don't pass, stop reviewing and ask the author to fix first.
Step 3 — Architecture invariants (manual review of the diff)
For each changed file under internal/ or cmd/:
| Check | Look for | If violated |
|---|---|---|
| Subprocess | New exec.Command / exec.CommandContext call |
Should be in internal/system or wrapped in a Runner. Reject + suggest internal/system.RunCommand. |
| HTTP | New http.NewRequest, http.Get, http.DefaultClient |
Should go through internal/httputil.Do. Reject + suggest wrapper. |
| Home dir | os.Getenv("HOME"), hardcoded /Users/..., hardcoded "~/" |
Use os.UserHomeDir(). |
| Error wrap | return err without context |
Should be fmt.Errorf("doing X: %w", err) unless the error is already wrapped one frame up. |
| UI output | fmt.Println, fmt.Printf in non-UI packages |
Use ui.Info, ui.Success, etc. (legacy violations are baselined — only flag NEW ones). |
| Dry run | New destructive operation (mkdir, write, exec, network mutate) | Must check cfg.DryRun and print [DRY-RUN] Would X instead. |
| Embedded data | New data/*.yaml or schema change |
Confirm fallback path still loads. |
| State path | New file under ~/.openboot/ |
Confirm the path is created via os.UserHomeDir(), perms are 0o600 for secrets / 0o755 for dirs. |
Step 4 — Test layer check
For each non-trivial change:
- Pure logic → must have an L1 test in
internal/<pkg>/. If missing, request it. - Subprocess interaction → fake via Runner in
internal/<pkg>/OR add a real-subprocess test undertest/integration/(still L1, no build tag). - CLI flag parsing → table-driven L1 test.
- Destructive op → must run cleanly under
--dry-runin a test.
If the change is small enough to land without tests (e.g. comment rewording, typo fix), say so explicitly rather than letting it pass unmentioned.
Step 5 — Behaviour invariants
| Check | Why it matters |
|---|---|
| Does the change break the curl|bash install path? | scripts/install.sh is the primary install vector. The smoke test CI job covers this — make sure it still passes. |
| Does the change alter the contract schema (config / snapshot JSON)? | If yes, the schema needs updating in openboot-contract repo and bumping. Otherwise the L2 contract job will fail. |
| Does the change add or change a CLI flag? | Confirm --help output is updated, and old-cli compat job still passes (previous release × new mock server). |
Does the change touch data/presets.yaml? |
Three presets must still parse and resolve. |
Does the change touch ~/.openboot/* file format? |
Confirm backward compat with old files (snapshot, auth, state) or write a migration. |
Step 6 — Risk assessment
End the review with:
- Risk: low / medium / high (one sentence on blast radius).
- Rollback: how a user / operator would revert (CLI flag, file delete, brew downgrade).
- Observability: what would tell us this broke in production (telemetry, GitHub issue pattern, smoke job).
What the reviewer SHOULD NOT do
- Do not approve a change that adds an archtest violation without an
updated
baseline/file and a justification in the commit message. - Do not approve mixed-purpose commits — request a split.
- Do not approve changes to
.github/workflows/without confirming the workflow still runs (actlocally or trigger on a draft PR). - Do not approve direct edits to
data/packages.yamlwithout confirming the source-of-truth is openboot.dev (see AGENTS.md "Where to look").
04 同仓库更多 Skills
ship-pr
暂无简介
bootstrap-feature
暂无简介
architecture-review
暂无简介
ship-pr
Use when the user is done editing and wants to ship the current branch via a pull request — phrases like "open a PR", "ship it", "ship this", "submit the PR", "let's send it", "merge it", "land this", "提 PR", "提个 PR", "提个 MR". Trigger whenever the user signals a change is finished and should head to the default branch, even if they don't say the word "PR". Walks the whole branch-to-merge flow for any GitHub repo with a mandatory review gate — the steps and their rules live in the body. Do NOT trigger for `gh pr view` / status checks on an existing PR, for draft / WIP PRs the user wants opened but not merged, or for cutting a release tag.
bootstrap-feature
Use when adding a new CLI subcommand or feature to openboot. Walks through the canonical pattern: cobra command registration, runner wiring, archtest awareness, and test placement. Trigger when the user says "add a command", "new subcommand", "implement feature X for the CLI", or starts editing under internal/cli/.