メニュー
ALWAYS invoke this skill when auditing ADRs for TypeScript or after writing an ADR. NEVER implement from an unaudited ADR.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
ALWAYS invoke this skill when auditing ADRs for Python or after writing an ADR. NEVER implement from an unaudited ADR.
ALWAYS invoke this skill when auditing code for Python or after writing code. NEVER modify a spec to match code without auditing the code first.
ALWAYS invoke this skill when auditing tests for Python or after writing tests. NEVER use auditing-python for test code.
Python ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.
ALWAYS invoke this skill when auditing PDRs or after writing a PDR. NEVER audit PDRs without this skill.
ALWAYS invoke this skill when auditing test evidence quality, after writing tests for a spec node, or before closing an outcome.
| name | auditing-typescript-architecture |
| description | ALWAYS invoke this skill when auditing ADRs for TypeScript or after writing an ADR. NEVER implement from an unaudited ADR. |
| allowed-tools | Read, Grep |
Read /standardizing-typescript-architecture before reviewing any ADR. It defines the canonical ADR sections, how testability appears in Compliance rules, and what does NOT belong in an ADR.
<context_loading> For spec-tree work items: Load complete ADR/PDR hierarchy before reviewing.
If you're reviewing ADRs for a spec-tree work item (enabler/outcome), ensure complete architectural context is loaded:
spec-tree:contextualizing with the node pathThe spec-tree:contextualizing skill provides:
Review focus:
If NOT working on spec-tree work item: Proceed directly with ADR review using provided architectural decision.
</context_loading>
/standardizing-typescript-architecture for canonical conventions<failure_modes>
These are real failures from past audits. Study them to avoid repeating them.
Approved code that passed linters but had a design flaw. The auditor trusted the tooling output (Phase 1 equivalent) and skimmed the Compliance section. The ADR mandated DI for all external calls, but the Compliance rules were so vague ("use good practices") that they couldn't catch anything. A Compliance rule that cannot falsify non-conforming code is not a rule.
Rejected an ADR for a false positive. The auditor flagged a parameter in a DI interface as "dead code" because it wasn't used in the example. The parameter was required by a Protocol contract that other implementations relied on. Before flagging dead parameters in interfaces, check if the interface is implemented elsewhere.
Missed mocking hidden behind DI. The ADR said "dependency injection" but described injecting vi.fn() as the controlled implementation. This is still mocking -- DI is the delivery mechanism, but vi.fn() is a mock. Correct DI injects a controlled real implementation (a simple function or object), not a mock framework spy.
Distracted by style while missing a logic flaw. The auditor spent review time on naming conventions and formatting while a branch condition in the Compliance rules was inverted -- the MUST and NEVER were swapped. Comprehension (understanding what the ADR actually says) must come before style concerns.
Accepted temporal language because it was in the Rationale section. The auditor assumed Rationale was exempt from atemporal voice because it explains "why." It is not exempt. "After evaluating options, we decided..." narrates decision history. Atemporal: "X was rejected because Y violates Z."
Flagged a phantom section but missed the real problem. The auditor correctly rejected a Testing Strategy section but didn't check whether the Compliance section had equivalent testability constraints. Removing a phantom section is not enough -- the testability constraints must appear somewhere in the ADR (in Compliance).
</failure_modes>
<principles_to_enforce>
All canonical conventions are in /standardizing-typescript-architecture. Read it first. The audit checks these specific concerns:
1. Section structure -- Only authoritative sections from the ADR template. See <adr_sections> in /standardizing-typescript-architecture for the complete list. Flag any section not in that list.
2. Testability in Compliance -- The Compliance section must include MUST/NEVER rules that enable appropriate testing. See <testability_in_compliance> in /standardizing-typescript-architecture for the correct pattern. Level assignment tables and Testing Strategy sections are violations.
3. Atemporal voice -- ADRs state architectural truth in ALL sections. See <atemporal_voice> in /standardizing-typescript-architecture for temporal patterns to reject and rewrite examples.
4. Mocking prohibition -- No mocking language anywhere in the ADR. See <di_patterns> in /standardizing-typescript-architecture for what to check and correct ADR language.
5. Level accuracy -- When the Compliance section references testing levels, verify against /testing definitions. See <level_context> in /standardizing-typescript-architecture. Key rule: SaaS services jump L1 to L3 (no Level 2).
6. Anti-patterns -- Check for content that does not belong in an ADR. See <anti_patterns> in /standardizing-typescript-architecture for the full table.
</principles_to_enforce>
<output_format>
# ARCHITECTURE REVIEW
**Decision:** [APPROVED | REJECTED]
## Verdict
| # | Concern | Status | Detail |
| - | --------------------- | ----------------- | ----------------- |
| 1 | Section structure | {PASS/REJECT} | {one-line detail} |
| 2 | Testability in Compl. | {PASS/REJECT} | {one-line detail} |
| 3 | Atemporal voice | {PASS/REJECT} | {one-line detail} |
| 4 | Mocking prohibition | {PASS/REJECT} | {one-line detail} |
| 5 | Level accuracy | {PASS/REJECT} | {one-line detail} |
| 6 | Anti-patterns | {PASS/REJECT} | {one-line detail} |
| 7 | Ancestor consistency | {PASS/REJECT/N/A} | {one-line detail} |
---
## Violations
### {Violation name}
**Where:** {Section name or quoted text identifying the location}
**Concern:** {Which concern from the verdict table}
**Why this fails:** {Direct explanation}
**Correct approach:**
```typescript
{Show what the architecture should be}
```
---
{Repeat for each violation}
---
## Required Changes
{Concise list of what must change}
---
## References
- /standardizing-typescript-architecture: {section name}
- /testing: {section name if applicable}
---
{If REJECTED: "Revise and resubmit."}
{If APPROVED: "Architecture meets standards."}
</output_format>
<what_to_avoid>
Don't:
Do:
/standardizing-typescript-architecture section names (e.g., <testability_in_compliance>, <atemporal_voice>)/testing section names for level rules (e.g., "Stage 2 Five Factors")</what_to_avoid>
<example_review>
Read ${SKILL_DIR}/references/example-review.md for a complete REJECTED review showing all concern types: phantom Testing Strategy section, missing testability in Compliance, mocking language, and temporal voice violations.
</example_review>
<success_criteria> Review is complete when:
/standardizing-typescript-architecture before starting review</success_criteria>