一键在 Manus 中运行任何 Skill

adr-scan

星标6

分支0

更新时间2026年7月15日 21:11

PROVISIONAL / one-off. Full-repository scan that discovers ADR-worthy architectural decisions across the whole repo (not just docs/decisions.md) so decisions.md can be migrated to a formal docs/adr/ set. Fans out read-only discovery over four surfaces — canonical docs (decisions/architecture/rules), subsystem design docs (docs/design/**), deliberate-exclusion docs (docs/project/**, out-of-scope), and latent decisions (per-package READMEs + code "why" comments) — classifying each candidate as decision (ADR-worthy) / rule (stays in rules.md) / inventory (stays in a living reference) / exclusion (ADR-worthy negative decision). Read-only: produces a candidate ADR inventory only, writes no docs/adr files. Delete after the migration format is locked.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

Tomy-ch

Tomy-ch/go-boilerplate

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

adr-scan (provisional)

Status: temporary. Built to drive the one-off decisions.md → docs/adr/ migration survey. Remove once the ADR skeleton/numbering is agreed. Read-only — never writes docs/adr/** or edits source; it only emits a candidate inventory.

Purpose

docs/decisions.md holds 8 explicit decisions, but architectural decisions are also scattered across design docs, rules, deliberate exclusions, and code comments. Before migrating to a formal per-file ADR set, discover the full ADR-worthy surface so the numbering and split are done once.

Classification taxonomy (the core judgment)

Each candidate is exactly one of:

decision — a choice among alternatives with lasting consequences (X over Y). ADR-worthy.
exclusion — a deliberate "we intentionally do NOT do X" with rationale. ADR-worthy (negative decision).
rule — a consequence/constraint enforced day-to-day (layer deps, DTO boundary). Stays in docs/rules.md; may reference an ADR but is not itself one.
inventory — a catalog that drifts with code (dependency table). Stays in a living reference doc, never an ADR.

A candidate is ADR-worthy only if: it has (or implies) considered alternatives, it is cross-cutting or hard to reverse, and it is not merely restating a rule/inventory.

Scan surfaces (fan out one worker each)

Canonical — docs/decisions.md, docs/architecture.md, docs/rules.md. Extract explicit decisions + rule-encoded decisions; separate decision vs rule.
Subsystem design — docs/design/*.md (idempotency / job / observability / outbox / rest / worker). Each design doc's "why / alternatives / trade-off" content.
Deliberate exclusions — docs/project/*.md (esp. out-of-scope.md), policy.md, scope.md. Negative decisions with rationale.
Latent — per-package README.md (Design Intent / Notes) + code // why rationale comments. Decisions made in code but never elevated to a doc.

Output (per candidate)

- title:        short decision title (imperative, ADR-style)
  type:         decision | exclusion | rule | inventory
  adr_worthy:   yes | no
  source:       file:line (evidence)
  alternatives: present | implied | none
  proposed_adr: which ADR bucket it belongs to (or existing 0001..N)
  note:         one line — why worthy / why not

Aggregate into: (A) ADR bucket list with proposed numbering, (B) rules-stay list, (C) inventory-stay list, (D) newly-discovered decisions not in decisions.md.

同仓库更多 Skills

同仓库

arch-check

Tomy-ch/go-boilerplate

Integrator skill for architectural compliance checks. Confirms scope + TODO opt via `AskUserQuestion` (changed files vs full repo), detects which layers are touched, resolves the file list and runs `make lint` ONCE, then fans out the relevant read-only `arch-auditor-*` subagents (`arch-auditor-domain` / `-usecase` / `-controller` / `-infra` / `-pkg`) IN PARALLEL via the Agent tool — passing scope + resolved files + the shared lint output so each auditor skips its own scope question and does not re-run lint. Aggregates findings into a single Japanese report grouped by layer. Each auditor enforces its own README rules + lean A conventions (controller / infra have additional convention enforcement since they're scaffold-derived, not spec-driven). Detection is delegated to the read-only auditor subagents; the integrator itself only writes the optional `// TODO:` hand-off comments (single-threaded, after aggregation) when the user opts in. To audit a single layer, run this integrator and pick that layer in the sco

2026-07-186

commit

Tomy-ch/go-boilerplate

Analyze the current working-tree changes (staged + unstaged), group them into appropriately-scoped commits with the project's prefix convention (Feat / Fix / Refactor / Perf / Docs / Test / Build / CI / Chore / Style / Revert), and execute each commit in Japanese after user approval. Pre-flight also checks whether the current branch's PR is already merged and, if so, recommends cutting a fresh branch from the base before committing. Commits are made with `git commit --no-verify` to skip lefthook during the split; after all commits succeed, the command runs the lefthook-defined commands directly plus `make fix` as a final verification gate (lefthook itself is bypassed because it skips checks when nothing is staged). Respects CLAUDE.md's git rules (no direct commits to protected branches, no force-push, no auto-push after PR amend, Co-Authored-By footer, HEREDOC commit messages).

2026-07-186

full-apply

Tomy-ch/go-boilerplate

The "apply" skill that applies = fixes the findings under tmp/reviews/ generated by full-verify (architecture.md / mod_*.md / _index.md), top-down by severity (Critical → High → Medium → Low). The counterpart to the read-only full-verify. Skips (defers) "suspicious" findings that require design judgment or whose behavior is unclear, leaving a reason. Tracks done/deferred in the tmp/reviews/working.md ledger and stamps a status comment + commit hash at the top of each mod_*.md. Conflicts are first-come-first-served; within one md, related findings are fixed together within the bounds of not breaking the public API. Verifies (build/vet/test/gofmt or make) before committing. Use it when asked to "fix the review findings", "apply reviews", or "full apply".

2026-07-186

full-verify

Tomy-ch/go-boilerplate

Verify a whole repository's architecture and the validity of all implementation code in the background, generating a set of Markdown findings (tmp/reviews/architecture.md / mod_*.md / _index.md). The skill itself detects and adapts to the language, structure, and presence of design documents. Use it when asked for a whole-repository structural verification / implementation-soundness review / overall review / full verify — NOT a diff review. Changes no code; read-only plus Markdown generation only.

2026-07-186

impl-review

Tomy-ch/go-boilerplate

Local adversarial, low-bias code review of the current change, run by subagents on a DIFFERENT model than the implementer. Mirrors `/code-review`'s finder → verify shape but keeps everything local and adds a runtime (curl + o11y) stage that mocked tests cannot cover. Confirms scope via `AskUserQuestion` (changed files vs branch-vs-base diff vs specific paths), fans out `adversarial-reviewer` subagents — one per lens (correctness / security / architecture / runtime-gap) — plus the dedicated `comment-reviewer` subagent for comment quality, each on a user-selected model (fable / sonnet / opus / haiku; default auto = a model ≠ the implementer) so reviewer ≠ implementer — then verifies each finding with an independent `review-verifier` subagent (CONFIRMED / PLAUSIBLE / REFUTED), optionally runs the runtime curl + o11y check for touched endpoints (orchestrator-driven, per `scaffold-endpoint` Step 3.5), and synthesizes a single Japanese report. The `comment-reviewer` both validates good comments (the What is correct

2026-07-186

scaffold-endpoint

Tomy-ch/go-boilerplate

End-to-end orchestrator that builds a complete onion-architecture endpoint (domain + infra-db + usecase + controller) for one feature — and, when you start from a rough idea instead of finished specs, first drives the feature-dev-style upstream design phases that turn that idea into the input artifacts the deterministic scaffold core needs. Two entry modes, auto-detected: (A) **idea-first** — Discovery + Clarifying Questions (AskUserQuestion) → parallel Codebase Exploration (Explore agents) → Architecture Design (Plan agent, constrained to the lean A / onion / OpenAPI-first / sqlc rails) → draft the OpenAPI YAML + SQL migration + domain.md + usecase.md for user review, then run `make gen-api` / `make gen-query`; (B) **specs-ready** (backward-compatible fast path) — jump straight to the core when `docs/spec/<feature>/{domain,usecase}.md` + OpenAPI + SQL already exist. The deterministic core is unchanged: `verify-spec` → `scaffold-domain` → `scaffold-infra-db` → `scaffold-usecase` → `scaffold-controller` → `mak

2026-07-186

name

adr-scan

description

adr-scan (provisional)

Purpose

Classification taxonomy (the core judgment)

Each candidate is exactly one of:

decision — a choice among alternatives with lasting consequences (X over Y). ADR-worthy.
exclusion — a deliberate "we intentionally do NOT do X" with rationale. ADR-worthy (negative decision).
rule — a consequence/constraint enforced day-to-day (layer deps, DTO boundary). Stays in docs/rules.md; may reference an ADR but is not itself one.
inventory — a catalog that drifts with code (dependency table). Stays in a living reference doc, never an ADR.

A candidate is ADR-worthy only if: it has (or implies) considered alternatives, it is cross-cutting or hard to reverse, and it is not merely restating a rule/inventory.

Scan surfaces (fan out one worker each)

Canonical — docs/decisions.md, docs/architecture.md, docs/rules.md. Extract explicit decisions + rule-encoded decisions; separate decision vs rule.
Subsystem design — docs/design/*.md (idempotency / job / observability / outbox / rest / worker). Each design doc's "why / alternatives / trade-off" content.
Deliberate exclusions — docs/project/*.md (esp. out-of-scope.md), policy.md, scope.md. Negative decisions with rationale.
Latent — per-package README.md (Design Intent / Notes) + code // why rationale comments. Decisions made in code but never elevated to a doc.

Output (per candidate)

- title:        short decision title (imperative, ADR-style)
  type:         decision | exclusion | rule | inventory
  adr_worthy:   yes | no
  source:       file:line (evidence)
  alternatives: present | implied | none
  proposed_adr: which ADR bucket it belongs to (or existing 0001..N)
  note:         one line — why worthy / why not

Aggregate into: (A) ADR bucket list with proposed numbering, (B) rules-stay list, (C) inventory-stay list, (D) newly-discovered decisions not in decisions.md.