Run any Skill in Manus with one click

adr-scan

Stars6

Forks0

UpdatedJuly 15, 2026 at 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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Tomy-ch

Tomy-ch/go-boilerplate

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name

adr-scan

description

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.

More from this repository

same repository

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.