[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71G09TEKCVK55PBMM60H2NV":3,"skill-same:01M71G09TEKCVK55PBMM60H2NV":86},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":14,"repositoryHtmlUrl":45,"repositoryHomepageUrl":6,"ownerHtmlUrl":46,"ownerBlogUrl":47,"ownerDescription":48,"updatedAt":49,"install":50,"resources":63},"01M71G09TEKCVK55PBMM60H2NV","author-python-architecture",null,"ALWAYS invoke this skill when writing ADRs for Python. NEVER author a Python ADR without this skill.","outcomeeng\u002Fplugins","outcomeeng","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F257335685?v=4","01M71FRVRF36XYR3HRSCGFHK2R","Outcome Engineering","01M71FRVS4BZG17DWANFJ7EPNY",1,"MIT","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"python","python architecture","architecture","author","author python architecture","when","invoke","use","writing","grep","write","writing adrs","tool","read","for","never","adr","2026-11-10 10:12:30",false,"---\nname: author-python-architecture\ndescription: >-\n  ALWAYS invoke this skill when writing ADRs for Python.\n  NEVER author a Python ADR without this skill.\nallowed-tools: Read, Write, Glob, Grep, {{! tool('use_skill') !}}\n---\n\n{!% require_skill 'python:python-code-standards' %!}\n\n{!% require_skill 'python:python-architecture-standards' %!}\n\n{!% require_skill 'python:python-test-standards' %!}\n\n\u003Cobjective>\nA binding Python ADR whose testability constraints live as ALWAYS\u002FNEVER rules under the `## Verification` section's `### Audit` subsection.\n\u003C\u002Fobjective>\n\n\u003Cfoundational_stance>\nStandards are pre-loaded by the `require_skill` directives above. `\u002Fpython-architecture-standards` defines the ADR sections; `\u002Fpython-test-standards` defines evidence, level, runner, and dependency-injection constraints.\n\n- An ADR follows the authoritative template: title + decision stated directly, Rationale, Invariants (optional), Verification.\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules — never in a separate Testing Strategy section.\n- Before writing any ADR, Use skill `product-tree:verify` for verification routing and Use skill `python:author-python-test` for Python test authoring.\n\n\u003C\u002Ffoundational_stance>\n\n\u003Crepo_local_overlay>\nAfter reading those standards, check for `spx\u002Flocal\u002Fpython.md`, `spx\u002Flocal\u002Fpython-tests.md`, and `spx\u002Flocal\u002Fpython-architecture.md` at the repository root. Read each file that exists and apply it as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cinputs>\nBefore creating ADRs, read:\n\n- **The node spec** — functional requirements, test strategy, outcomes, and architectural constraints from parent ADRs\u002FPDRs.\n- **Product context** — the active root harness guide for navigation, node status, and sparse-integer index dependencies.\n- **Existing decisions** — product-level `spx\u002F{NN}-{slug}.adr.md` \u002F `.pdr.md` and decisions interleaved within enabler\u002Foutcome nodes, so new ADRs stay consistent.\n\n\u003C\u002Finputs>\n\n\u003Coutputs>\nThe skill produces ADRs at the scope of the decision:\n\n| Decision scope | ADR location                                     | Example                                |\n| -------------- | ------------------------------------------------ | -------------------------------------- |\n| Product-wide   | `spx\u002F{NN}-{slug}.adr.md`                         | \"Use Pydantic for all data validation\" |\n| Node-specific  | `spx\u002F{NN}-{slug}.enabler\u002F{NN}-{slug}.adr.md`     | \"Clone tree approach for snapshots\"    |\n| Nested node    | `spx\u002F...\u002F{NN}-{slug}.outcome\u002F{NN}-{slug}.adr.md` | \"Use rclone sync with --checksum\"      |\n\nADR numbering uses the sparse integer index [10, 99]; a lower index is a dependency that higher-index ADRs may rely on. Insert at `floor((left + right) \u002F 2)`, append at `floor((last + 99) \u002F 2)`, and use 21 for the first ADR in scope. Within a scope, adr-21 is decided before adr-37. Cross-scope dependencies are documented explicitly in the ADR's decision statement using markdown links. See `\u002Fauthor` for the complete ordering rules.\n\u003C\u002Foutputs>\n\n\u003Cadr_creation_protocol>\nExecute these phases in order.\n\n**Phase 0 — Read context.** Read every `\u003Cinputs>` artifact, apply `\u003Cfoundational_stance>`, and read existing ADRs for consistency. The canonical ADR section structure is owned by the `\u002Funderstand` foundation's decision template and represented by `\u002Fpython-architecture-standards` `\u003Cadr_sections>`; author to that shape rather than reaching across plugins for the template file.\n\n**Phase 1 — Identify decisions needed.** For each requirement, ask what architectural choices it implies, what patterns to mandate, what constraints to impose, and what trade-offs are made. List the decisions before writing any ADR.\n\n**Phase 2 — Analyze Python-specific implications.** For each decision, consider the type system (annotations, protocols), the architecture pattern, security boundaries, and testability. See `\u003Carchitectural_principles>`, which links the per-concern reference file for each.\n\n**Phase 3 — Write ADRs.** Use the authoritative template, decision-first:\n\n1. Title + decision: `# {Decision Name}`, then the decision stated directly as permanent truth in 1–3 sentences. No `Purpose` heading, no `Context` section; business impact and constraints fold into the decision statement and Rationale.\n2. Rationale: why this is right given the constraints; name a rejected alternative only when it sharpens the decision.\n3. Invariants (optional): algebraic properties for all governed code.\n4. Verification: ALWAYS\u002FNEVER rules grouped under `### Testing` (`[{assertion type}]`), `### Eval` (`[eval]`), `### Audit` (`[audit:{rule-slug}]`, a slug unique within the ADR), ordered by decreasing enforcement strength; the dependency-injection testability constraints are `### Audit` rules carrying `([audit:{rule-slug}])`.\n\n**Phase 4 — Verify consistency.** No ADR contradicts another; node ADRs align with ancestor ADRs; nested ADRs do not contradict parent-level ADRs.\n\n**Phase 5 — Return authored ADRs.** Report each canonical ADR path, decision summary, and binding architecture constraints. Audit dispatch and implementation sequencing remain outside this skill.\n\nCommon violations to avoid: a phantom Testing Strategy section, `l2` assigned to SaaS services, \"mock at boundary\" language for external services, missing DI Protocol interfaces in `## Verification` (`### Audit`), and any mocking language in the ADR.\n\u003C\u002Fadr_creation_protocol>\n\n\u003Carchitectural_principles>\nThese principles guide every ADR. Each links to the reference carrying the full patterns and code examples.\n\n- **Type safety first** — modern syntax (`X | None`, `list[str]`), no unjustified `Any`, protocols for structural typing, Pydantic at boundaries. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftype-system-patterns.md`.\n- **Clean architecture** — DDD entities\u002Fvalue objects\u002Faggregates, dependency injection through parameters not globals, single responsibility, no circular imports. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Farchitecture-patterns.md`.\n- **Security by design** — validate at boundaries, no hardcoded secrets, array-arg subprocess (never `shell=True`), context-aware threat modeling. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsecurity-patterns.md`.\n- **Testability by design** — design for dependency injection (no mocking), prefer pure functions and observable boundaries, and establish constraints that let `product-tree:test` select the minimum execution level that gives confidence. ADRs never assign execution levels. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftestability-patterns.md`.\n\n\u003C\u002Farchitectural_principles>\n\n\u003Cconstraints>\n- NEVER write implementation code — write ADRs that constrain implementation.\n- NEVER review code or repair implementation defects — this skill authors ADRs only.\n\n\u003C\u002Fconstraints>\n\n\u003Coutput_format>\nOutput:\n\n```markdown\n## Architectural Decisions Created\n\n### ADRs Written\n\n| ADR                         | Scope   | Decision Summary            |\n| --------------------------- | ------- | --------------------------- |\n| [{ADR Name}]({path to ADR}) | {scope} | {one-line decision summary} |\n\n### Binding Constraints\n\n1. {constraint from the ADR}\n2. {verification rule from the ADR}\n```\n\n\u003C\u002Foutput_format>\n\n\u003Cadr_patterns>\nThese patterns show how testability constraints appear under `## Verification`'s `### Audit` subsection. See `\u002Fpython-architecture-standards` for the canonical section structure.\n\n**External tool integration** — dependency injection for every external tool invocation:\n\n```markdown\n### Audit\n\n- ALWAYS: functions that call external tools accept a `runner` parameter implementing the `CommandRunner` Protocol -- enables `l1` testing of command-building logic ([audit:runner-protocol-parameter])\n- ALWAYS: default implementations use `subprocess`; tests inject controlled implementations -- no mocking ([audit:default-subprocess-injected-controls])\n- NEVER: direct `subprocess.run` without a DI wrapper -- prevents isolated testing ([audit:no-direct-subprocess-run])\n```\n\n**Configuration loading** — validated models for all configuration:\n\n```markdown\n### Audit\n\n- ALWAYS: config files have corresponding Pydantic models -- type-safe, validated config ([audit:config-pydantic-models])\n- ALWAYS: config loading validates at load time with `.model_validate()` -- fail fast with descriptive errors ([audit:config-validated-at-load])\n- NEVER: unvalidated config access at use time -- defers errors to runtime ([audit:no-unvalidated-config-access])\n- NEVER: `Any` type annotations on config fields -- bypasses validation ([audit:no-any-config-fields])\n```\n\n**Test infrastructure** — packaged `{product}_testing\u002F` for products with co-located tests:\n\n```markdown\n### Audit\n\n- ALWAYS: test infrastructure (generators, harnesses, fixtures) lives in `{product}_testing\u002F`, NOT `tests\u002F` -- generators and harnesses importable as a package, fixtures consumed by path ([audit:testing-package-outside-tests])\n- ALWAYS: `pyproject.toml` includes both packages: `packages = [\"{product}\", \"{product}_testing\"]` ([audit:pyproject-both-packages])\n- ALWAYS: pytest config uses `--import-mode=importlib` for multiple test directories ([audit:pytest-importlib-mode])\n- NEVER: test infrastructure in the `tests\u002F` directory -- not importable by product-tree co-located tests ([audit:no-infrastructure-in-tests])\n```\n\nSee `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-infrastructure-patterns.md` for the full pattern.\n\n**CLI structure** — subcommand pattern with injected dependencies:\n\n```markdown\n### Audit\n\n- ALWAYS: each command is a separate module exporting a registration function -- enables isolated `l1` testing ([audit:command-per-module])\n- ALWAYS: commands delegate to runner functions that accept Protocol-typed DI parameters -- separates parsing from logic ([audit:commands-delegate-to-runners])\n- NEVER: business logic in command handlers -- prevents isolated testing ([audit:no-logic-in-handlers])\n- NEVER: direct I\u002FO in command modules without DI -- couples commands to environment ([audit:no-direct-io-in-commands])\n```\n\n\u003C\u002Fadr_patterns>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftype-system-patterns.md` — Python type-system guidance\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Farchitecture-patterns.md` — DDD, hexagonal, DI patterns\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsecurity-patterns.md` — security-by-design patterns\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftestability-patterns.md` — designing for testability\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-infrastructure-patterns.md` — test packaging, pytest config, environment verification\n\n\u003C\u002Freference_guides>\n\n\u003Cfailure_modes>\n\n**Claude assigned execution levels inside an ADR**\n\n- **What happened:** Claude assigned `l1`, `l2`, or `l3` to components while authoring the architecture decision.\n- **Why it failed:** Execution level depends on a spec assertion's evidence and operational environment; `\u002Ftest` owns that selection after the ADR establishes architectural constraints.\n- **How to avoid:** Write dependency-injection, observability, safety, and boundary constraints in the ADR and leave execution-level selection to `\u002Ftest`.\n\n**Claude introduced a noncanonical ADR section**\n\n- **What happened:** Claude added Security Context, Testing Strategy, Purpose, Context, or Trade-offs as a separate ADR section.\n- **Why it failed:** The authoritative template's section list is complete; extra sections produce decisions the structural auditor rejects.\n- **How to avoid:** Fold business, threat-model, and trade-off reasoning into the decision statement and Rationale, then place enforceable rules under Verification.\n\n**Claude reintroduced mocking-positive guidance**\n\n- **What happened:** Claude described Protocols or dependency injection as a way to inject mocks and used mock-named collaborators in examples.\n- **Why it failed:** The architecture then recommends a testing mechanism its own no-mocking rules reject.\n- **How to avoid:** Describe injected real or controlled implementations, recording collaborators, and spies that preserve the behavior boundary.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- Every ADR follows the authoritative template (decision-first; Rationale; optional Invariants; Verification with `### Testing` \u002F `### Eval` \u002F `### Audit`).\n- Testability constraints appear as ALWAYS\u002FNEVER `([audit:{rule-slug}])` rules under `## Verification`'s `### Audit` subsection, never in a separate Testing Strategy section.\n- No mocking language anywhere; external SaaS services are never assigned `l2`.\n- ADRs establish architecture constraints without assigning execution levels.\n- ADRs are placed and numbered per `\u003Coutputs>`, consistent with ancestor and sibling decisions.\n\n\u003C\u002Fsuccess_criteria>\n","{!% require_skill 'python:python-code-standards' %!}\n\n{!% require_skill 'python:python-architecture-standards' %!}\n\n{!% require_skill 'python:python-test-standards' %!}\n\n\u003Cobjective>\nA binding Python ADR whose testability constraints live as ALWAYS\u002FNEVER rules under the `## Verification` section's `### Audit` subsection.\n\u003C\u002Fobjective>\n\n\u003Cfoundational_stance>\nStandards are pre-loaded by the `require_skill` directives above. `\u002Fpython-architecture-standards` defines the ADR sections; `\u002Fpython-test-standards` defines evidence, level, runner, and dependency-injection constraints.\n\n- An ADR follows the authoritative template: title + decision stated directly, Rationale, Invariants (optional), Verification.\n- Testability constraints go under `## Verification`'s `### Audit` subsection as ALWAYS\u002FNEVER rules — never in a separate Testing Strategy section.\n- Before writing any ADR, Use skill `product-tree:verify` for verification routing and Use skill `python:author-python-test` for Python test authoring.\n\n\u003C\u002Ffoundational_stance>\n\n\u003Crepo_local_overlay>\nAfter reading those standards, check for `spx\u002Flocal\u002Fpython.md`, `spx\u002Flocal\u002Fpython-tests.md`, and `spx\u002Flocal\u002Fpython-architecture.md` at the repository root. Read each file that exists and apply it as repo-local routing to the product's governing specs and decisions. A local overlay supplements skill behavior; it does not declare product truth.\n\u003C\u002Frepo_local_overlay>\n\n\u003Cinputs>\nBefore creating ADRs, read:\n\n- **The node spec** — functional requirements, test strategy, outcomes, and architectural constraints from parent ADRs\u002FPDRs.\n- **Product context** — the active root harness guide for navigation, node status, and sparse-integer index dependencies.\n- **Existing decisions** — product-level `spx\u002F{NN}-{slug}.adr.md` \u002F `.pdr.md` and decisions interleaved within enabler\u002Foutcome nodes, so new ADRs stay consistent.\n\n\u003C\u002Finputs>\n\n\u003Coutputs>\nThe skill produces ADRs at the scope of the decision:\n\n| Decision scope | ADR location                                     | Example                                |\n| -------------- | ------------------------------------------------ | -------------------------------------- |\n| Product-wide   | `spx\u002F{NN}-{slug}.adr.md`                         | \"Use Pydantic for all data validation\" |\n| Node-specific  | `spx\u002F{NN}-{slug}.enabler\u002F{NN}-{slug}.adr.md`     | \"Clone tree approach for snapshots\"    |\n| Nested node    | `spx\u002F...\u002F{NN}-{slug}.outcome\u002F{NN}-{slug}.adr.md` | \"Use rclone sync with --checksum\"      |\n\nADR numbering uses the sparse integer index [10, 99]; a lower index is a dependency that higher-index ADRs may rely on. Insert at `floor((left + right) \u002F 2)`, append at `floor((last + 99) \u002F 2)`, and use 21 for the first ADR in scope. Within a scope, adr-21 is decided before adr-37. Cross-scope dependencies are documented explicitly in the ADR's decision statement using markdown links. See `\u002Fauthor` for the complete ordering rules.\n\u003C\u002Foutputs>\n\n\u003Cadr_creation_protocol>\nExecute these phases in order.\n\n**Phase 0 — Read context.** Read every `\u003Cinputs>` artifact, apply `\u003Cfoundational_stance>`, and read existing ADRs for consistency. The canonical ADR section structure is owned by the `\u002Funderstand` foundation's decision template and represented by `\u002Fpython-architecture-standards` `\u003Cadr_sections>`; author to that shape rather than reaching across plugins for the template file.\n\n**Phase 1 — Identify decisions needed.** For each requirement, ask what architectural choices it implies, what patterns to mandate, what constraints to impose, and what trade-offs are made. List the decisions before writing any ADR.\n\n**Phase 2 — Analyze Python-specific implications.** For each decision, consider the type system (annotations, protocols), the architecture pattern, security boundaries, and testability. See `\u003Carchitectural_principles>`, which links the per-concern reference file for each.\n\n**Phase 3 — Write ADRs.** Use the authoritative template, decision-first:\n\n1. Title + decision: `# {Decision Name}`, then the decision stated directly as permanent truth in 1–3 sentences. No `Purpose` heading, no `Context` section; business impact and constraints fold into the decision statement and Rationale.\n2. Rationale: why this is right given the constraints; name a rejected alternative only when it sharpens the decision.\n3. Invariants (optional): algebraic properties for all governed code.\n4. Verification: ALWAYS\u002FNEVER rules grouped under `### Testing` (`[{assertion type}]`), `### Eval` (`[eval]`), `### Audit` (`[audit:{rule-slug}]`, a slug unique within the ADR), ordered by decreasing enforcement strength; the dependency-injection testability constraints are `### Audit` rules carrying `([audit:{rule-slug}])`.\n\n**Phase 4 — Verify consistency.** No ADR contradicts another; node ADRs align with ancestor ADRs; nested ADRs do not contradict parent-level ADRs.\n\n**Phase 5 — Return authored ADRs.** Report each canonical ADR path, decision summary, and binding architecture constraints. Audit dispatch and implementation sequencing remain outside this skill.\n\nCommon violations to avoid: a phantom Testing Strategy section, `l2` assigned to SaaS services, \"mock at boundary\" language for external services, missing DI Protocol interfaces in `## Verification` (`### Audit`), and any mocking language in the ADR.\n\u003C\u002Fadr_creation_protocol>\n\n\u003Carchitectural_principles>\nThese principles guide every ADR. Each links to the reference carrying the full patterns and code examples.\n\n- **Type safety first** — modern syntax (`X | None`, `list[str]`), no unjustified `Any`, protocols for structural typing, Pydantic at boundaries. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftype-system-patterns.md`.\n- **Clean architecture** — DDD entities\u002Fvalue objects\u002Faggregates, dependency injection through parameters not globals, single responsibility, no circular imports. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Farchitecture-patterns.md`.\n- **Security by design** — validate at boundaries, no hardcoded secrets, array-arg subprocess (never `shell=True`), context-aware threat modeling. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsecurity-patterns.md`.\n- **Testability by design** — design for dependency injection (no mocking), prefer pure functions and observable boundaries, and establish constraints that let `product-tree:test` select the minimum execution level that gives confidence. ADRs never assign execution levels. See `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftestability-patterns.md`.\n\n\u003C\u002Farchitectural_principles>\n\n\u003Cconstraints>\n- NEVER write implementation code — write ADRs that constrain implementation.\n- NEVER review code or repair implementation defects — this skill authors ADRs only.\n\n\u003C\u002Fconstraints>\n\n\u003Coutput_format>\nOutput:\n\n```markdown\n## Architectural Decisions Created\n\n### ADRs Written\n\n| ADR                         | Scope   | Decision Summary            |\n| --------------------------- | ------- | --------------------------- |\n| [{ADR Name}]({path to ADR}) | {scope} | {one-line decision summary} |\n\n### Binding Constraints\n\n1. {constraint from the ADR}\n2. {verification rule from the ADR}\n```\n\n\u003C\u002Foutput_format>\n\n\u003Cadr_patterns>\nThese patterns show how testability constraints appear under `## Verification`'s `### Audit` subsection. See `\u002Fpython-architecture-standards` for the canonical section structure.\n\n**External tool integration** — dependency injection for every external tool invocation:\n\n```markdown\n### Audit\n\n- ALWAYS: functions that call external tools accept a `runner` parameter implementing the `CommandRunner` Protocol -- enables `l1` testing of command-building logic ([audit:runner-protocol-parameter])\n- ALWAYS: default implementations use `subprocess`; tests inject controlled implementations -- no mocking ([audit:default-subprocess-injected-controls])\n- NEVER: direct `subprocess.run` without a DI wrapper -- prevents isolated testing ([audit:no-direct-subprocess-run])\n```\n\n**Configuration loading** — validated models for all configuration:\n\n```markdown\n### Audit\n\n- ALWAYS: config files have corresponding Pydantic models -- type-safe, validated config ([audit:config-pydantic-models])\n- ALWAYS: config loading validates at load time with `.model_validate()` -- fail fast with descriptive errors ([audit:config-validated-at-load])\n- NEVER: unvalidated config access at use time -- defers errors to runtime ([audit:no-unvalidated-config-access])\n- NEVER: `Any` type annotations on config fields -- bypasses validation ([audit:no-any-config-fields])\n```\n\n**Test infrastructure** — packaged `{product}_testing\u002F` for products with co-located tests:\n\n```markdown\n### Audit\n\n- ALWAYS: test infrastructure (generators, harnesses, fixtures) lives in `{product}_testing\u002F`, NOT `tests\u002F` -- generators and harnesses importable as a package, fixtures consumed by path ([audit:testing-package-outside-tests])\n- ALWAYS: `pyproject.toml` includes both packages: `packages = [\"{product}\", \"{product}_testing\"]` ([audit:pyproject-both-packages])\n- ALWAYS: pytest config uses `--import-mode=importlib` for multiple test directories ([audit:pytest-importlib-mode])\n- NEVER: test infrastructure in the `tests\u002F` directory -- not importable by product-tree co-located tests ([audit:no-infrastructure-in-tests])\n```\n\nSee `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-infrastructure-patterns.md` for the full pattern.\n\n**CLI structure** — subcommand pattern with injected dependencies:\n\n```markdown\n### Audit\n\n- ALWAYS: each command is a separate module exporting a registration function -- enables isolated `l1` testing ([audit:command-per-module])\n- ALWAYS: commands delegate to runner functions that accept Protocol-typed DI parameters -- separates parsing from logic ([audit:commands-delegate-to-runners])\n- NEVER: business logic in command handlers -- prevents isolated testing ([audit:no-logic-in-handlers])\n- NEVER: direct I\u002FO in command modules without DI -- couples commands to environment ([audit:no-direct-io-in-commands])\n```\n\n\u003C\u002Fadr_patterns>\n\n\u003Creference_guides>\n\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftype-system-patterns.md` — Python type-system guidance\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Farchitecture-patterns.md` — DDD, hexagonal, DI patterns\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Fsecurity-patterns.md` — security-by-design patterns\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftestability-patterns.md` — designing for testability\n- `${CLAUDE_SKILL_DIR}\u002Freferences\u002Ftest-infrastructure-patterns.md` — test packaging, pytest config, environment verification\n\n\u003C\u002Freference_guides>\n\n\u003Cfailure_modes>\n\n**Claude assigned execution levels inside an ADR**\n\n- **What happened:** Claude assigned `l1`, `l2`, or `l3` to components while authoring the architecture decision.\n- **Why it failed:** Execution level depends on a spec assertion's evidence and operational environment; `\u002Ftest` owns that selection after the ADR establishes architectural constraints.\n- **How to avoid:** Write dependency-injection, observability, safety, and boundary constraints in the ADR and leave execution-level selection to `\u002Ftest`.\n\n**Claude introduced a noncanonical ADR section**\n\n- **What happened:** Claude added Security Context, Testing Strategy, Purpose, Context, or Trade-offs as a separate ADR section.\n- **Why it failed:** The authoritative template's section list is complete; extra sections produce decisions the structural auditor rejects.\n- **How to avoid:** Fold business, threat-model, and trade-off reasoning into the decision statement and Rationale, then place enforceable rules under Verification.\n\n**Claude reintroduced mocking-positive guidance**\n\n- **What happened:** Claude described Protocols or dependency injection as a way to inject mocks and used mock-named collaborators in examples.\n- **Why it failed:** The architecture then recommends a testing mechanism its own no-mocking rules reject.\n- **How to avoid:** Describe injected real or controlled implementations, recording collaborators, and spies that preserve the behavior boundary.\n\n\u003C\u002Ffailure_modes>\n\n\u003Csuccess_criteria>\n\n- Every ADR follows the authoritative template (decision-first; Rationale; optional Invariants; Verification with `### Testing` \u002F `### Eval` \u002F `### Audit`).\n- Testability constraints appear as ALWAYS\u002FNEVER `([audit:{rule-slug}])` rules under `## Verification`'s `### Audit` subsection, never in a separate Testing Strategy section.\n- No mocking language anywhere; external SaaS services are never assigned `l2`.\n- ADRs establish architecture constraints without assigning execution levels.\n- ADRs are placed and numbered per `\u003Coutputs>`, consistent with ancestor and sibling decisions.\n\n\u003C\u002Fsuccess_criteria>\n",{"name":5,"description":7,"allowed-tools":41},"Read, Write, Glob, Grep, {{! tool('use_skill') !}}","main","978d51c51d68c99cffb2ba48f7cad9d2f07e5738","src\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins","https:\u002F\u002Fgithub.com\u002Foutcomeeng","https:\u002F\u002Foutcome.engineering","Spec-driven development for AI-assisted engineering","2026-11-13 22:49:15",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add outcomeeng\u002Fplugins --skill author-python-architecture",{"tool":56,"command":57},"bunx","bunx skills add outcomeeng\u002Fplugins --skill author-python-architecture",{"tool":59,"command":60},"pnpm","pnpm dlx skills add outcomeeng\u002Fplugins --skill author-python-architecture","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002FSKILL.md",true,[64,70,74,78,82],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Farchitecture-patterns.md","REFERENCE","参考文档",13604,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002Freferences\u002Farchitecture-patterns.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fsecurity-patterns.md",12651,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002Freferences\u002Fsecurity-patterns.md",{"path":75,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Ftest-infrastructure-patterns.md",8377,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002Freferences\u002Ftest-infrastructure-patterns.md",{"path":79,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Ftestability-patterns.md",13671,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002Freferences\u002Ftestability-patterns.md",{"path":83,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Ftype-system-patterns.md",9245,"https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fpython\u002Fskills\u002Fauthor-python-architecture\u002Freferences\u002Ftype-system-patterns.md",[87,93,127,143,159,172],{"skillNo":88,"name":89,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":36},"01M71G25RZTPQG9KJ00JCHC1F7","plugin","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Ftemplates\u002Fplugin\u002FSKILL.md",[],[89],{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":109,"publishedAt":36},"01M71G23DCX3SV60H63HBBKQ6J","sanitize-powerpoint","ALWAYS invoke this skill when sanitizing, cleaning up, auditing, or aligning a PowerPoint (.pptx) deck — slide-master and layout structure, layout type attributes, stray fonts, non-theme colors, or layout naming. NEVER hand-edit pptx XML without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fsanitize-powerpoint\u002FSKILL.md",[99,104],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000003","演示文稿","SCENARIO","使用场景",{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000034","行政与办公人员","PROFESSION","适用职业",[110,111,112,113,114,115,116,34,117,118,119,120,121,122,123,124,125,126,25,24],"sanitize powerpoint","powerpoint","sanitize","fonts","type","cleaning","structure","attributes","theme","pptx","naming","layout","deck","up","edit","xml","master",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":133,"publishedAt":36},"01M71G21PQKBCDECHGVYSKPJW5","draw-excalidraw","ALWAYS invoke this skill when creating Excalidraw diagrams, visualizing workflows, architectures, or concepts. NEVER generate Excalidraw JSON without this skill.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Fwork\u002Fskills\u002Fdraw-excalidraw\u002FSKILL.md",[],[134,135,136,137,138,34,25,139,140,24,141,142],"draw excalidraw","excalidraw","draw","diagrams","architectures","generate","workflows","concepts","json",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":152,"publishedAt":36},"01M71G1ZMNGFD37RZYM620XM2C","typescript-test-standards","TypeScript test standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-test-standards\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000008","测试与质量",[153,154,155,156,157,32,158],"typescript","typescript test standards","test","standards","false","across",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":168,"publishedAt":36},"01M71G1XBH0X1VCTR7269MDGSY","typescript-code-standards","TypeScript code standards enforced across all skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-code-standards\u002FSKILL.md",[165],{"categoryNo":166,"categoryName":167,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000030","开发工程师",[153,169,170,171,156,157,32,158],"code","typescript code standards","code standards",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":178,"publishedAt":36},"01M71G1TQ3VN45SJ75DFMJDB9W","typescript-architecture-standards","TypeScript ADR conventions enforced across architect and auditor skills. Loaded by other skills, not invoked directly.","https:\u002F\u002Fgithub.com\u002Foutcomeeng\u002Fplugins\u002Fblob\u002Fmain\u002Fsrc\u002Fplugins\u002Ftypescript\u002Fskills\u002Ftypescript-architecture-standards\u002FSKILL.md",[],[179,156,180,21,153,35,181,158,32,182,157,183],"architecture standards","typescript architecture standards","architect","auditor","conventions"]