[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6RTTYYYMHXJ43YMJWH0G1FP":3,"skill-same:01M6RTTYYYMHXJ43YMJWH0G1FP":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":13,"repositoryHtmlUrl":49,"repositoryHomepageUrl":6,"ownerHtmlUrl":50,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M6RTTYYYMHXJ43YMJWH0G1FP","cpp-coding-standards",null,"C++ coding standards based on the C++ Core Guidelines (isocpp.github.io). Use when writing, reviewing, or refactoring C++ code to enforce modern, safe, and idiomatic practices.","sakamoto-family-smile\u002Fagent_monorepo","sakamoto-family-smile","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F132812403?v=4","01M6RTAT3H8PMWX5SJ65KP3VYF","01M6RTAV321WB5RAHCWTZMX5CV",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fcpp-coding-standards\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"cpp","coding standards","standards","cpp coding standards","coding","when","writing","idiomatic","io","c++","enforce","use","refactoring","code","core","guidelines","github","safe","2026-11-10 10:12:30",false,"---\nname: architecture-review\ndescription: \"Adversarial, code-grounded review of an existing system's architecture: do the ADRs match the code, is the design right for a system of this nature, what are its inherent limitations and what concretely would have been better, every alternative proven against the code. Use when asked 'is our architecture sound' or 'what should we change about the design', for technical due diligence, before a major architectural commitment, or at milestone health checks. Not for one delivered ticket (code-review), decay across deliveries (rot-watch) or defect hunting (defect-sweep).\"\nargument-hint: \"[system slug]\"\ncontext: fork\neffort: xhigh\n---\n\n# Architecture Review Skill\n\n## Purpose\n\nAdversarial, code-grounded review of an existing system's architecture. It answers three questions, in order:\n\n1. **Is it real?** Does the running code match the architecture decision records (ADRs), or has the documentation run ahead of the implementation? \"Real\" is established by reading the source, not by trusting ADRs or docstrings.\n2. **Is it good?** Not \"is each decision locally defensible\" (a low bar almost everything clears) but \"is this how a system *of this nature* should be designed?\"\n3. **What are its inherent limitations, and what would concretely have been a better decision?** Every alternative must be proven against the actual code and shown as a runnable sketch — never a vendor reflex.\n\nThis operates at the **system-architecture altitude** and is deliberately adversarial. It is distinct from the other skills: `technical-design` *produces* forward-looking design; `audit` checks `.gener8v\u002F` artifact consistency; `code-review` \u002F `quality-review` \u002F `security-review` operate at the per-delivery code altitude. Architecture Review critiques the architecture of a system that already exists.\n\n## When to Use\n\n- An architect or stakeholder asks \"is our architecture sound?\" \u002F \"what should we change?\"\n- Technical due diligence — acquisition, investment, or inheriting a codebase\n- Before a major architectural commitment (adopting a datastore, a workflow engine, a new boundary)\n- When a system has accumulated many ADRs and you want to test design against shipped reality\n- Periodic architecture health checks at slice\u002Fmilestone boundaries\n\n## Input\n\n**Source:** The codebase (the source of truth for \"real\"), plus whatever architecture intent exists.\n**Read from:**\n- The implementation — entry points, the core subsystem(s), the data layer, orchestration\u002Fcontrol plane, config, IaC, CI\n- Architecture decision records \u002F style-of-record docs \u002F fitness functions \u002F risk registers, if present\n- Existing per-ticket reviews (optional — to map onto, not duplicate): security reviews from `.gener8v\u002Fchanges\u002F*\u002Freviews\u002F*-security-review.md` (and the legacy `.gener8v\u002Freviews\u002F*-security-review.md`), quality and code reviews alongside them, and any system-level OWASP assessment in `.gener8v\u002Freviews\u002F`\n\n**Expects:** Code to exist. Architecture intent docs are helpful but optional; with none, derive the implicit architecture from the code and assess that.\n\n## Output\n\n**Produces:** A code-grounded, adversarial architecture assessment.\n**Write to:** `.gener8v\u002Freviews\u002F\u003Csystem-slug>-architecture-assessment.md`\n**Creates directory:** `.gener8v\u002Freviews\u002F` if absent.\n\n## Output Format\n\n```markdown\n# [System]: Architecture Assessment\n\n## 1. Verdict\n[Lead with the sharp theses (T1\u002FT2\u002FT3...), each one sentence. State the headline tension.]\n\n## 2. Is It Real? (from the code, not the ADRs)\n[Conformance table: each Accepted decision -> verified in source? Confirm Proposed\u002FRFC items are genuinely unbuilt. Substance-vs-stub evidence (line counts, real calls, test counts). The gaps the doc surface hides.]\n\n## 3. Is the Style Locally Sound? (necessary, not sufficient)\n[Brief: yes\u002Fno on the narrow \"reasonable v0 style\" question — then state why that is a low bar.]\n\n## 4. Adversarial: Is This How a System of This Nature Should Be Designed?\n[2-4 theses. For each: the critique (code-cited) -> inherent limitation -> what would have been better (concrete sketch + real gotchas) -> steelman.]\n\n## 5. Inherent Limitations\n## 6. What the Team Got Right (fairness \u002F steelman)\n## 7. Recommendations (prioritized, concrete)\n## 8. Open Questions for the Architect\n## 9. Bottom Line\n```\n\n## Principles\n\n### Real Comes From Code, Not ADRs\nAn ADR is a claim; a docstring is a claim; only the code is evidence. For every \"Accepted\" decision, find it in the source. For every \"Proposed\u002FRFC\" decision, confirm it is genuinely *not* half-built (grep for the would-be imports\u002Ftables). Distinguish substance from stubs: line counts, whether functions actually do the work (e.g. a stage that calls the model vs. a `pass` body), real test counts and `skip`\u002F`xfail` counts. The most valuable finding is often the gap between the documentation surface and what runs.\n\n### Local Soundness Is a Low Bar\n\"Each decision is individually defensible\" is almost always true and almost always beside the point. A series of reasonable decisions can compose into a system structurally wrong for its purpose. Always first ask: *what kind of system is this, really?* (a data pipeline? a CRUD app? an event system? an ML product? a ledger?) Then ask whether the architecture matches that nature — and name the mismatch when it doesn't.\n\n### No Vendor or Tool Reflex — Prove It or Drop It\n\"Adopt Temporal \u002F Dagster \u002F Kafka \u002F a graph DB\" is worthless as a reflex. Any \"X would be better\" claim must be proven *from this codebase*: the specific lines and failure modes it would replace, what it would **and would not** save, and the honest new cost it imposes (operational surface, learning curve). Quantify (e.g. \"740 of 1,252 lines are domain persistence no engine would save; the replaceable control plane is ~350\"). If you cannot prove it against the code, do not make the claim. When the code contradicts your first instinct, **retract it explicitly** — a visible retraction is what makes the rest of the review credible.\n\n### Better-Decisions Must Be Concrete\n\"Use row-level security\" is a slogan. A migration (`ENABLE ROW LEVEL SECURITY` + `CREATE POLICY ...`), the wiring change, and the three gotchas that actually bite (non-owner role, the resolution chicken-and-egg, per-checkout transaction scoping) is a defensible alternative. Show runnable sketches — SQL, schema, code — with their real caveats. The caveats are not optional; they are what separate engineering judgment from name-dropping.\n\n### Find the Design-to-Validation Ratio\nCount what is *decided* versus what is *validated by running code*. Thirty ADRs and one end-to-end path is an inversion. Watch for the twin smell: **over-building in one dimension while under-building another** (a DAG engine executing a strictly linear pipeline; an elaborate recovery detector that is written, tested, and never wired in). Both are failures of *where* effort went, and both are code-provable.\n\n### Critique Risk Sequencing, Not Just Risk Presence\nRight-thing-wrong-time is a finding. Ask which risks were deferred and which were hardened. If the existential risks for a system of this nature (tenant isolation of sensitive data, correctness\u002Fgroundedness of outputs sold to customers, data-loss\u002Fconsistency) were postponed while cheap invariants were polished, that inversion is the headline — even when every individual deferral was \"reasonable for the slice.\"\n\n### Adversarial, But Fair\nSteelman every critique and include an honest \"what the team got right.\" Note where a deferral is genuinely correct for the stage. Adversarial without credibility is just contrarian; the goal is feedback on the quality of reality, delivered so it survives the architect's pushback.\n\n### Quantify and Cite\n`file:line`, line counts, grep results, test counts. \"It's over-engineered\" is an opinion; \"Kahn's-algorithm topological sort + cycle detection in `stages\u002F__init__.py`, but `next_stage()` is `order.index(current)+1` — a DAG engine running a linked list\" is a finding.\n\n## Process\n\n1. **Name the system's nature.** Before judging the architecture, state what kind of system this actually is. Everything downstream tests fit-to-nature.\n2. **Inventory the intent.** Read the style-of-record, ADRs (split Accepted vs Proposed\u002FRFC), fitness functions, and risk register. Note what is claimed.\n3. **Reality audit (code is truth).** For each Accepted decision, verify in source. Confirm Proposed items are genuinely unbuilt (grep for absence). Substance-vs-stub: line counts, real work vs placeholders, test counts and skips. Record the gaps the doc surface hides.\n4. **Local soundness (brief).** Answer the narrow \"reasonable style?\" question, then explicitly mark it as necessary-not-sufficient.\n5. **Adversarial pass.** Develop 2-4 theses about whether a system of this nature should be built this way. Ground each in cited code. Read the actual control plane \u002F core subsystem deeply enough to be specific.\n6. **For each thesis:** critique -> inherent limitation -> concrete better-decision (sketch + gotchas) -> steelman. Kill any claim you cannot prove from the code; retract overstatements visibly.\n7. **Design-to-validation ratio + risk sequencing.** Make these explicit findings.\n8. **Recommendations.** Prioritized, concrete, cheap-first. Distinguish \"wire what you already built\" from \"adopt a new substrate\" and give the *trigger* for the latter rather than recommending it by default.\n9. **Open questions for the architect.** The load-bearing decisions still unmade.\n10. **Write the report.**\n\n## Example (abbreviated — from a real review)\n\n> **T1 — Silent ownership of execution correctness, mis-invested.** The product is an LLM data-pipeline, but it runs on a task queue (`arq`), so the team owns durability by hand. Reading the runtime: ~740 of `orchestrator.py`'s 1,252 lines are irreducible domain persistence **no workflow engine would save** (retract the reflexive \"adopt Dagster\"). The genuine findings are opposite-signed: they *over-built* a DAG substrate (Kahn's sort, cycle detection) to run a **strictly linear** pipeline (`next_stage()` = `index+1`), and *under-built* recovery — `find_stale_running_stages()` is written, tested, and **never wired** (grep: referenced only by tests + `__all__`), so a dead worker strands an audit until a human notices. Better-decision is therefore **not** \"adopt a vendor\" but \"wire the recovery you already built (~1 hr), add backoff, and write the ADR naming the *trigger* for a durable executor (pipeline goes non-linear \u002F resume-from-step becomes an SLA need).\" Steelman: for a tiny team migrating off a prototype, hand-rolled-but-wired is right.\n\n## Troubleshooting\n\n- **The review assessed the wrong system, or ignored what the conversation was about.** This skill runs in a forked subagent that sees the skill and its arguments, not the conversation. Put the system slug and the focus in the argument — `\u002Fgener8v:architecture-review ingestion — the tenancy model and the job queue`. With no slug, take the repository directory name and state that choice in the Verdict.\n- **Orchestrate does not list the assessment.** It globs `.gener8v\u002Freviews\u002F*-assessment.md`; the file must be `.gener8v\u002Freviews\u002F\u003Csystem-slug>-architecture-assessment.md`. A report written elsewhere, or under another suffix, is invisible to it and to the next re-run's carry-forward.\n- **A re-run dropped the previous theses.** Revisions requires carrying each one forward as addressed, still open or retracted. Read the existing `\u003Csystem-slug>-architecture-assessment.md` before writing; a re-run under a different slug starts a second assessment instead of replacing the first.\n- **The core subsystem is too large to read deeply in one run.** The method fails when the control plane is skimmed. Narrow the argument to the subsystem that carries the system's nature, read it properly, and name what was not read under Open Questions — an unread subsystem left unmentioned reads as one that passed.\n\n## Integration with Other Skills\n\n**Upstream:** Technical Design (the forward design this reviews against); Security Review \u002F OWASP reviews (map their SEC-NNN onto architecture concerns, e.g. tenant isolation, denial-of-wallet — cite them qualified with the change segment, `\u003Cchange-slug>\u002F\u003Carea-slug>-ticket-NNN-security-review\u002FSEC-NNN`, since finding numbers restart per report).\n**Parallel:** Quality Review (code altitude) — different altitude, complementary.\n**Downstream:** Audit (can fold architecture findings into a cross-stage assessment); Ticket Breakdown (recommendations that need code changes become tickets); Orchestrate (lists the assessment under `cross_cutting.assessments` and recommends one at milestone boundaries).\n\n## Revisions\n\n- Re-run when the architecture changes materially (new datastore, new boundary, a deferred risk coming due) and at milestone boundaries; the report is point-in-time.\n- Re-running replaces `\u003Csystem-slug>-architecture-assessment.md`; carry forward the previous theses with their current status (addressed \u002F still open \u002F retracted).\n\n## Notes\n\n- Adversarial by design. The point is to pressure-test reality, not validate it — but every critique must be fair (steelman) and provable (code-cited).\n- Re-run when the architecture changes materially (new datastore, new boundary, a deferred risk coming due).\n- This skill reads code deeply — budget for reading the actual control plane \u002F core subsystem, not just the ADRs. The whole method depends on it.\n- Define software acronyms (DAG, RLS, CRUD, ...) at first use; these reports are read by mixed audiences.\n","# Architecture Review Skill\n\n## Purpose\n\nAdversarial, code-grounded review of an existing system's architecture. It answers three questions, in order:\n\n1. **Is it real?** Does the running code match the architecture decision records (ADRs), or has the documentation run ahead of the implementation? \"Real\" is established by reading the source, not by trusting ADRs or docstrings.\n2. **Is it good?** Not \"is each decision locally defensible\" (a low bar almost everything clears) but \"is this how a system *of this nature* should be designed?\"\n3. **What are its inherent limitations, and what would concretely have been a better decision?** Every alternative must be proven against the actual code and shown as a runnable sketch — never a vendor reflex.\n\nThis operates at the **system-architecture altitude** and is deliberately adversarial. It is distinct from the other skills: `technical-design` *produces* forward-looking design; `audit` checks `.gener8v\u002F` artifact consistency; `code-review` \u002F `quality-review` \u002F `security-review` operate at the per-delivery code altitude. Architecture Review critiques the architecture of a system that already exists.\n\n## When to Use\n\n- An architect or stakeholder asks \"is our architecture sound?\" \u002F \"what should we change?\"\n- Technical due diligence — acquisition, investment, or inheriting a codebase\n- Before a major architectural commitment (adopting a datastore, a workflow engine, a new boundary)\n- When a system has accumulated many ADRs and you want to test design against shipped reality\n- Periodic architecture health checks at slice\u002Fmilestone boundaries\n\n## Input\n\n**Source:** The codebase (the source of truth for \"real\"), plus whatever architecture intent exists.\n**Read from:**\n- The implementation — entry points, the core subsystem(s), the data layer, orchestration\u002Fcontrol plane, config, IaC, CI\n- Architecture decision records \u002F style-of-record docs \u002F fitness functions \u002F risk registers, if present\n- Existing per-ticket reviews (optional — to map onto, not duplicate): security reviews from `.gener8v\u002Fchanges\u002F*\u002Freviews\u002F*-security-review.md` (and the legacy `.gener8v\u002Freviews\u002F*-security-review.md`), quality and code reviews alongside them, and any system-level OWASP assessment in `.gener8v\u002Freviews\u002F`\n\n**Expects:** Code to exist. Architecture intent docs are helpful but optional; with none, derive the implicit architecture from the code and assess that.\n\n## Output\n\n**Produces:** A code-grounded, adversarial architecture assessment.\n**Write to:** `.gener8v\u002Freviews\u002F\u003Csystem-slug>-architecture-assessment.md`\n**Creates directory:** `.gener8v\u002Freviews\u002F` if absent.\n\n## Output Format\n\n```markdown\n# [System]: Architecture Assessment\n\n## 1. Verdict\n[Lead with the sharp theses (T1\u002FT2\u002FT3...), each one sentence. State the headline tension.]\n\n## 2. Is It Real? (from the code, not the ADRs)\n[Conformance table: each Accepted decision -> verified in source? Confirm Proposed\u002FRFC items are genuinely unbuilt. Substance-vs-stub evidence (line counts, real calls, test counts). The gaps the doc surface hides.]\n\n## 3. Is the Style Locally Sound? (necessary, not sufficient)\n[Brief: yes\u002Fno on the narrow \"reasonable v0 style\" question — then state why that is a low bar.]\n\n## 4. Adversarial: Is This How a System of This Nature Should Be Designed?\n[2-4 theses. For each: the critique (code-cited) -> inherent limitation -> what would have been better (concrete sketch + real gotchas) -> steelman.]\n\n## 5. Inherent Limitations\n## 6. What the Team Got Right (fairness \u002F steelman)\n## 7. Recommendations (prioritized, concrete)\n## 8. Open Questions for the Architect\n## 9. Bottom Line\n```\n\n## Principles\n\n### Real Comes From Code, Not ADRs\nAn ADR is a claim; a docstring is a claim; only the code is evidence. For every \"Accepted\" decision, find it in the source. For every \"Proposed\u002FRFC\" decision, confirm it is genuinely *not* half-built (grep for the would-be imports\u002Ftables). Distinguish substance from stubs: line counts, whether functions actually do the work (e.g. a stage that calls the model vs. a `pass` body), real test counts and `skip`\u002F`xfail` counts. The most valuable finding is often the gap between the documentation surface and what runs.\n\n### Local Soundness Is a Low Bar\n\"Each decision is individually defensible\" is almost always true and almost always beside the point. A series of reasonable decisions can compose into a system structurally wrong for its purpose. Always first ask: *what kind of system is this, really?* (a data pipeline? a CRUD app? an event system? an ML product? a ledger?) Then ask whether the architecture matches that nature — and name the mismatch when it doesn't.\n\n### No Vendor or Tool Reflex — Prove It or Drop It\n\"Adopt Temporal \u002F Dagster \u002F Kafka \u002F a graph DB\" is worthless as a reflex. Any \"X would be better\" claim must be proven *from this codebase*: the specific lines and failure modes it would replace, what it would **and would not** save, and the honest new cost it imposes (operational surface, learning curve). Quantify (e.g. \"740 of 1,252 lines are domain persistence no engine would save; the replaceable control plane is ~350\"). If you cannot prove it against the code, do not make the claim. When the code contradicts your first instinct, **retract it explicitly** — a visible retraction is what makes the rest of the review credible.\n\n### Better-Decisions Must Be Concrete\n\"Use row-level security\" is a slogan. A migration (`ENABLE ROW LEVEL SECURITY` + `CREATE POLICY ...`), the wiring change, and the three gotchas that actually bite (non-owner role, the resolution chicken-and-egg, per-checkout transaction scoping) is a defensible alternative. Show runnable sketches — SQL, schema, code — with their real caveats. The caveats are not optional; they are what separate engineering judgment from name-dropping.\n\n### Find the Design-to-Validation Ratio\nCount what is *decided* versus what is *validated by running code*. Thirty ADRs and one end-to-end path is an inversion. Watch for the twin smell: **over-building in one dimension while under-building another** (a DAG engine executing a strictly linear pipeline; an elaborate recovery detector that is written, tested, and never wired in). Both are failures of *where* effort went, and both are code-provable.\n\n### Critique Risk Sequencing, Not Just Risk Presence\nRight-thing-wrong-time is a finding. Ask which risks were deferred and which were hardened. If the existential risks for a system of this nature (tenant isolation of sensitive data, correctness\u002Fgroundedness of outputs sold to customers, data-loss\u002Fconsistency) were postponed while cheap invariants were polished, that inversion is the headline — even when every individual deferral was \"reasonable for the slice.\"\n\n### Adversarial, But Fair\nSteelman every critique and include an honest \"what the team got right.\" Note where a deferral is genuinely correct for the stage. Adversarial without credibility is just contrarian; the goal is feedback on the quality of reality, delivered so it survives the architect's pushback.\n\n### Quantify and Cite\n`file:line`, line counts, grep results, test counts. \"It's over-engineered\" is an opinion; \"Kahn's-algorithm topological sort + cycle detection in `stages\u002F__init__.py`, but `next_stage()` is `order.index(current)+1` — a DAG engine running a linked list\" is a finding.\n\n## Process\n\n1. **Name the system's nature.** Before judging the architecture, state what kind of system this actually is. Everything downstream tests fit-to-nature.\n2. **Inventory the intent.** Read the style-of-record, ADRs (split Accepted vs Proposed\u002FRFC), fitness functions, and risk register. Note what is claimed.\n3. **Reality audit (code is truth).** For each Accepted decision, verify in source. Confirm Proposed items are genuinely unbuilt (grep for absence). Substance-vs-stub: line counts, real work vs placeholders, test counts and skips. Record the gaps the doc surface hides.\n4. **Local soundness (brief).** Answer the narrow \"reasonable style?\" question, then explicitly mark it as necessary-not-sufficient.\n5. **Adversarial pass.** Develop 2-4 theses about whether a system of this nature should be built this way. Ground each in cited code. Read the actual control plane \u002F core subsystem deeply enough to be specific.\n6. **For each thesis:** critique -> inherent limitation -> concrete better-decision (sketch + gotchas) -> steelman. Kill any claim you cannot prove from the code; retract overstatements visibly.\n7. **Design-to-validation ratio + risk sequencing.** Make these explicit findings.\n8. **Recommendations.** Prioritized, concrete, cheap-first. Distinguish \"wire what you already built\" from \"adopt a new substrate\" and give the *trigger* for the latter rather than recommending it by default.\n9. **Open questions for the architect.** The load-bearing decisions still unmade.\n10. **Write the report.**\n\n## Example (abbreviated — from a real review)\n\n> **T1 — Silent ownership of execution correctness, mis-invested.** The product is an LLM data-pipeline, but it runs on a task queue (`arq`), so the team owns durability by hand. Reading the runtime: ~740 of `orchestrator.py`'s 1,252 lines are irreducible domain persistence **no workflow engine would save** (retract the reflexive \"adopt Dagster\"). The genuine findings are opposite-signed: they *over-built* a DAG substrate (Kahn's sort, cycle detection) to run a **strictly linear** pipeline (`next_stage()` = `index+1`), and *under-built* recovery — `find_stale_running_stages()` is written, tested, and **never wired** (grep: referenced only by tests + `__all__`), so a dead worker strands an audit until a human notices. Better-decision is therefore **not** \"adopt a vendor\" but \"wire the recovery you already built (~1 hr), add backoff, and write the ADR naming the *trigger* for a durable executor (pipeline goes non-linear \u002F resume-from-step becomes an SLA need).\" Steelman: for a tiny team migrating off a prototype, hand-rolled-but-wired is right.\n\n## Troubleshooting\n\n- **The review assessed the wrong system, or ignored what the conversation was about.** This skill runs in a forked subagent that sees the skill and its arguments, not the conversation. Put the system slug and the focus in the argument — `\u002Fgener8v:architecture-review ingestion — the tenancy model and the job queue`. With no slug, take the repository directory name and state that choice in the Verdict.\n- **Orchestrate does not list the assessment.** It globs `.gener8v\u002Freviews\u002F*-assessment.md`; the file must be `.gener8v\u002Freviews\u002F\u003Csystem-slug>-architecture-assessment.md`. A report written elsewhere, or under another suffix, is invisible to it and to the next re-run's carry-forward.\n- **A re-run dropped the previous theses.** Revisions requires carrying each one forward as addressed, still open or retracted. Read the existing `\u003Csystem-slug>-architecture-assessment.md` before writing; a re-run under a different slug starts a second assessment instead of replacing the first.\n- **The core subsystem is too large to read deeply in one run.** The method fails when the control plane is skimmed. Narrow the argument to the subsystem that carries the system's nature, read it properly, and name what was not read under Open Questions — an unread subsystem left unmentioned reads as one that passed.\n\n## Integration with Other Skills\n\n**Upstream:** Technical Design (the forward design this reviews against); Security Review \u002F OWASP reviews (map their SEC-NNN onto architecture concerns, e.g. tenant isolation, denial-of-wallet — cite them qualified with the change segment, `\u003Cchange-slug>\u002F\u003Carea-slug>-ticket-NNN-security-review\u002FSEC-NNN`, since finding numbers restart per report).\n**Parallel:** Quality Review (code altitude) — different altitude, complementary.\n**Downstream:** Audit (can fold architecture findings into a cross-stage assessment); Ticket Breakdown (recommendations that need code changes become tickets); Orchestrate (lists the assessment under `cross_cutting.assessments` and recommends one at milestone boundaries).\n\n## Revisions\n\n- Re-run when the architecture changes materially (new datastore, new boundary, a deferred risk coming due) and at milestone boundaries; the report is point-in-time.\n- Re-running replaces `\u003Csystem-slug>-architecture-assessment.md`; carry forward the previous theses with their current status (addressed \u002F still open \u002F retracted).\n\n## Notes\n\n- Adversarial by design. The point is to pressure-test reality, not validate it — but every critique must be fair (steelman) and provable (code-cited).\n- Re-run when the architecture changes materially (new datastore, new boundary, a deferred risk coming due).\n- This skill reads code deeply — budget for reading the actual control plane \u002F core subsystem, not just the ADRs. The whole method depends on it.\n- Define software acronyms (DAG, RLS, CRUD, ...) at first use; these reports are read by mixed audiences.\n",{"name":41,"effort":42,"context":43,"description":44,"argument-hint":45},"architecture-review","xhigh","fork","Adversarial, code-grounded review of an existing system's architecture: do the ADRs match the code, is the design right for a system of this nature, what are its inherent limitations and what concretely would have been better, every alternative proven against the code. Use when asked 'is our architecture sound' or 'what should we change about the design', for technical due diligence, before a major architectural commitment, or at milestone health checks. Not for one delivered ticket (code-review), decay across deliveries (rot-watch) or defect hunting (defect-sweep).","[system slug]","main","26f591c601503d32ccba54a6ddbcba75a00910c0",".claude\u002Fskills\u002Fecc\u002Fcpp-coding-standards","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile","2026-11-08 20:29:14",{"source":8,"skillName":41,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add sakamoto-family-smile\u002Fagent_monorepo --skill architecture-review",{"tool":58,"command":59},"bunx","bunx skills add sakamoto-family-smile\u002Fagent_monorepo --skill architecture-review",{"tool":61,"command":62},"pnpm","pnpm dlx skills add sakamoto-family-smile\u002Fagent_monorepo --skill architecture-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fcpp-coding-standards\u002FSKILL.md",true,[],[67,102,110,129,152,179],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":81,"publishedAt":36},"01M6RW50THEFSKK42YNR8XFZA1","remotion-video-creation","Best practices for Remotion - Video creation in React. 29 domain-specific rules covering 3D, animations, audio, captions, charts, transitions, and more.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fremotion-video-creation\u002FSKILL.md",[73,78],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":79,"categoryName":80,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000016","图像与多媒体",[82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101],"Video","remotion video","remotion video creation","creation","Remotion","Charts","Captions","Audio","3D","Composition","Animation","best practices","more","animations","domain-specific","domain","three","Rules","Lottie","for",{"skillNo":103,"name":104,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":36},"01M6VCJ23NPECPSZJKGY691F75","hotcook-recipes","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fhotcook-agent\u002Fdata\u002Fskills\u002Fhotcook-recipes\u002FSKILL.md",[],[108,109],"hotcook recipes","recipes",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":124,"publishedAt":36},"01M6VCHHE00X5XHSDRD1KH1BW2","code-helper","Code review and assistance skill","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-2\u002Fskills\u002Fcode-helper\u002Fskill.md",[116,119],{"categoryNo":117,"categoryName":118,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[125,126,31,127,128],"code helper","helper","code review","review",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":141,"publishedAt":36},"01M6VCH3Q31A20H6SQ1H0J7JB2","research-assistant","Web research assistant skill using Brave Search MCP","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002Fagent-system-1\u002Fskills\u002Fresearch-assistant\u002Fskill.md",[135,138],{"categoryNo":136,"categoryName":137,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":139,"categoryName":140,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发",[142,143,144,145,146,147,148,149,150,151],"research assistant","research","assistant","MCP","web","search","brave search","web research","brave","web research assistant",{"skillNo":153,"name":154,"nameZh":6,"description":155,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":156,"categories":157,"keywords":162,"publishedAt":36},"01M6VCGZZGPNVJSCZ1JTMNZAHY","x-api","X\u002FTwitter API integration for posting tweets, threads, reading timelines, search, and analytics. Covers OAuth auth patterns, rate limits, and platform-native content posting. Use when the user wants to interact with X programmatically.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fx-api\u002FSKILL.md",[158,161],{"categoryNo":159,"categoryName":160,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[163,164,165,23,166,167,101,168,169,170,171,172,173,174,175,29,176,177,147,178],"x api","api","with","limits","rate","threads","reading","native","posting","platform","patterns","api integration","twitter","auth","analytics","OAuth",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":186,"publishedAt":36},"01M6VCGVX6DGB1FKTA53QBBCQB","workspace-surface-audit","Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment.","https:\u002F\u002Fgithub.com\u002Fsakamoto-family-smile\u002Fagent_monorepo\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fecc\u002Fworkspace-surface-audit\u002FSKILL.md",[185],{"categoryNo":139,"categoryName":140,"taxonomyType":76,"taxonomyTypeDesc":77},[187,188,189,190,145,191,192,31,193,194,195,196,29,197,198,199,200,170,201,23],"workspace surface audit","workspace","audit","hooks","workflows","connectors","capabilities","harness","repo","environment","up","harness setup","active","env","value"]