powershell-module-architect
PowerShell 5.1と7+の両方で動作するモジュールの設計、関数構造、再利用可能なライブラリ、プロファイルの最適化、バージョン間の互換性を実現するSkill。
📜 元の英語説明(参考)
Use when user needs PowerShell module design, function structure, reusable libraries, profile optimization, or cross-version compatibility across PowerShell 5.1 and PowerShell 7+.
🇯🇵 日本人クリエイター向け解説
PowerShell 5.1と7+の両方で動作するモジュールの設計、関数構造、再利用可能なライブラリ、プロファイルの最適化、バージョン間の互換性を実現するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o powershell-module-architect.zip https://jpskill.com/download/6714.zip && unzip -o powershell-module-architect.zip && rm powershell-module-architect.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/6714.zip -OutFile "$d\powershell-module-architect.zip"; Expand-Archive "$d\powershell-module-architect.zip" -DestinationPath $d -Force; ri "$d\powershell-module-architect.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
powershell-module-architect.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
powershell-module-architectフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
PowerShellモジュールアーキテクト
目的
構造化され、再利用可能で、保守しやすいPowerShellモジュールの作成に特化した、PowerShellモジュールの設計およびアーキテクチャに関する専門知識を提供します。エンタープライズPowerShell環境向けのモジュールアーキテクチャ、関数設計、クロスバージョン互換性、およびプロファイル最適化に焦点を当てています。
使用する場面
- 散在するスクリプトを構造化された再利用可能なモジュールに変換する場合
- パブリック/プライベート関数の分離を伴うモジュールアーキテクチャを設計する場合
- クロスバージョン互換性のあるモジュール(PowerShell 5.1 & 7+)を作成する場合
- PowerShellプロファイルを最適化して読み込み時間を短縮する場合
- 適切なパラメーター検証を備えた高度な関数を構築する場合
クイックスタート
このスキルを呼び出すのは、次の場合です。
- 散在するスクリプトを構造化された再利用可能なモジュールに変換する場合
- パブリック/プライベート関数の分離を伴うモジュールアーキテクチャを設計する場合
- クロスバージョン互換性のあるモジュール(PowerShell 5.1 & 7+)を作成する場合
- PowerShellプロファイルを最適化して読み込み時間を短縮する場合
- 適切なパラメーター検証を備えた高度な関数を構築する場合
呼び出さないのは、次の場合です。
- 再利用しない単純な使い捨てスクリプト(powershell-5.1-expertまたはpowershell-7-expertを使用してください)
- 既に適切に構造化されたモジュールに機能を追加する必要がある場合(関連するドメインスキルを使用してください)
- UI開発(powershell-ui-architectを使用してください)
- セキュリティ強化(powershell-security-hardeningを使用してください)
意思決定フレームワーク
モジュールを作成するタイミング
| シナリオ | 推奨 |
|---|---|
| 3つ以上の関連関数 | モジュールを作成 |
| チーム間での共有が必要 | モジュール + マニフェストを作成 |
| 単一用途の自動化 | スクリプトのまま |
| 複雑なパラメーターセット | モジュール内の高度な関数 |
| バージョン互換性が必要 | 互換性レイヤーを持つモジュール |
モジュール構造の決定
Script Organization Need
│
├─ Few related functions (3-10)?
│ └─ Single .psm1 with inline functions
│
├─ Many functions (10+)?
│ └─ Dot-source pattern (Public/Private folders)
│
├─ Publishing to gallery?
│ └─ Full manifest + tests + docs
│
└─ Team collaboration?
└─ Git repo + CI/CD + Pester tests
コアワークフロー:スクリプトをモジュールに変換する
ユースケース: 10~50個の散在する.ps1スクリプトを整理されたモジュールにリファクタリングする
ステップ1:分析
# Inventory existing scripts
$scripts = Get-ChildItem -Path ./scripts -Filter *.ps1 -Recurse
# Analyze function signatures
foreach ($script in $scripts) {
$content = Get-Content $script.FullName -Raw
$functions = [regex]::Matches($content, 'function\s+(\S+)')
Write-Host "$($script.Name): $($functions.Count) functions"
}
# Expected output:
# AD-UserManagement.ps1: 12 functions
# AD-GroupManagement.ps1: 8 functions
# Common-Helpers.ps1: 15 functions (candidates for Private/)
ステップ2:モジュール構造の設計
# Create module skeleton
$moduleName = "Organization.ActiveDirectory"
$modulePath = "./modules/$moduleName"
New-Item -Path "$modulePath/Public" -ItemType Directory -Force
New-Item -Path "$modulePath/Private" -ItemType Directory -Force
New-Item -Path "$modulePath/Tests" -ItemType Directory -Force
New-Item -Path "$modulePath/$moduleName.psm1" -ItemType File -Force
New-Item -Path "$modulePath/$moduleName.psd1" -ItemType File -Force
ステップ3:関数の分類
Public functions (exported to users):
├─ Get-OrgADUser
├─ New-OrgADUser
├─ Set-OrgADUser
├─ Remove-OrgADUser
└─ ... (user-facing functions)
Private functions (internal helpers):
├─ _ValidateDomainConnection
├─ _BuildDistinguishedName
├─ _ConvertToCanonicalName
└─ ... (utility functions)
ステップ4:モジュールファイルの実装
# Organization.ActiveDirectory.psm1
# Dot-source Private functions first
$Private = @(Get-ChildItem -Path $PSScriptRoot\Private\*.ps1 -ErrorAction SilentlyContinue)
foreach ($import in $Private) {
try {
. $import.FullName
} catch {
Write-Error "Failed to import private function $($import.FullName): $_"
}
}
# Dot-source Public functions
$Public = @(Get-ChildItem -Path $PSScriptRoot\Public\*.ps1 -ErrorAction SilentlyContinue)
foreach ($import in $Public) {
try {
. $import.FullName
} catch {
Write-Error "Failed to import public function $($import.FullName): $_"
}
}
# Export Public functions explicitly
Export-ModuleMember -Function $Public.BaseName
ステップ5:モジュールマニフェストの作成
# Generate manifest
$manifestParams = @{
Path = "$modulePath/$moduleName.psd1"
RootModule = "$moduleName.psm1"
ModuleVersion = '1.0.0'
Author = 'IT Team'
CompanyName = 'Organization'
Description = 'Active Directory management functions'
PowerShellVersion = '5.1' # Minimum version
FunctionsToExport = @(
'Get-OrgADUser',
'New-OrgADUser',
'Set-OrgADUser',
'Remove-OrgADUser'
)
VariablesToExport = @()
AliasesToExport = @()
}
New-ModuleManifest @manifestParams
ステップ6:Pesterテストの追加
# Tests/Module.Tests.ps1
BeforeAll {
Import-Module "$PSScriptRoot/../Organization.ActiveDirectory.psd1" -Force
}
Describe "Organization.ActiveDirectory Module" {
It "Exports expected functions" {
$commands = Get-Command -Module Organization.ActiveDirectory
$commands.Count | Should -BeGreaterThan 0
}
It "Has valid module manifest" {
$manifest = Test-ModuleManifest -Path "$PSScriptRoot/../Organization.ActiveDirectory.psd1"
$manifest.Version | Should -Be '1.0.0'
}
}
Describe "Get-OrgADUser" {
It "Accepts Identity parameter" {
{ Get-OrgADUser -Identity "testuser" -WhatIf } | Should -Not -Throw
}
}
クイックリファレンス:高度な関数テンプレート
function Get-OrgUser {
<#
.SYNOPSIS
Retrieves Active Directory user by name.
.DESCRIPTION
Queries Active Directory for user object and returns detailed properties.
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
PowerShell Module Architect
Purpose
Provides PowerShell module design and architecture expertise specializing in creating structured, reusable, and maintainable PowerShell modules. Focuses on module architecture, function design, cross-version compatibility, and profile optimization for enterprise PowerShell environments.
When to Use
- Transforming scattered scripts into structured, reusable modules
- Designing module architecture with public/private function separation
- Creating cross-version compatible modules (PowerShell 5.1 & 7+)
- Optimizing PowerShell profiles for faster load times
- Building advanced functions with proper parameter validation
Quick Start
Invoke this skill when:
- Transforming scattered scripts into structured, reusable modules
- Designing module architecture with public/private function separation
- Creating cross-version compatible modules (PowerShell 5.1 & 7+)
- Optimizing PowerShell profiles for faster load times
- Building advanced functions with proper parameter validation
Do NOT invoke when:
- Simple one-off scripts that won't be reused (use powershell-5.1-expert or powershell-7-expert)
- Already have well-structured modules needing functionality additions (use relevant domain skill)
- UI development (use powershell-ui-architect instead)
- Security hardening (use powershell-security-hardening instead)
Decision Framework
When to Create a Module
| Scenario | Recommendation |
|---|---|
| 3+ related functions | Create module |
| Cross-team sharing needed | Create module + manifest |
| Single-use automation | Keep as script |
| Complex parameter sets | Advanced function in module |
| Version compatibility needed | Module with compatibility layer |
Module Structure Decision
Script Organization Need
│
├─ Few related functions (3-10)?
│ └─ Single .psm1 with inline functions
│
├─ Many functions (10+)?
│ └─ Dot-source pattern (Public/Private folders)
│
├─ Publishing to gallery?
│ └─ Full manifest + tests + docs
│
└─ Team collaboration?
└─ Git repo + CI/CD + Pester tests
Core Workflow: Transform Scripts into Module
Use case: Refactor 10-50 scattered .ps1 scripts into organized module
Step 1: Analysis
# Inventory existing scripts
$scripts = Get-ChildItem -Path ./scripts -Filter *.ps1 -Recurse
# Analyze function signatures
foreach ($script in $scripts) {
$content = Get-Content $script.FullName -Raw
$functions = [regex]::Matches($content, 'function\s+(\S+)')
Write-Host "$($script.Name): $($functions.Count) functions"
}
# Expected output:
# AD-UserManagement.ps1: 12 functions
# AD-GroupManagement.ps1: 8 functions
# Common-Helpers.ps1: 15 functions (candidates for Private/)
Step 2: Design Module Structure
# Create module skeleton
$moduleName = "Organization.ActiveDirectory"
$modulePath = "./modules/$moduleName"
New-Item -Path "$modulePath/Public" -ItemType Directory -Force
New-Item -Path "$modulePath/Private" -ItemType Directory -Force
New-Item -Path "$modulePath/Tests" -ItemType Directory -Force
New-Item -Path "$modulePath/$moduleName.psm1" -ItemType File -Force
New-Item -Path "$modulePath/$moduleName.psd1" -ItemType File -Force
Step 3: Categorize Functions
Public functions (exported to users):
├─ Get-OrgADUser
├─ New-OrgADUser
├─ Set-OrgADUser
├─ Remove-OrgADUser
└─ ... (user-facing functions)
Private functions (internal helpers):
├─ _ValidateDomainConnection
├─ _BuildDistinguishedName
├─ _ConvertToCanonicalName
└─ ... (utility functions)
Step 4: Implement Module File
# Organization.ActiveDirectory.psm1
# Dot-source Private functions first
$Private = @(Get-ChildItem -Path $PSScriptRoot\Private\*.ps1 -ErrorAction SilentlyContinue)
foreach ($import in $Private) {
try {
. $import.FullName
} catch {
Write-Error "Failed to import private function $($import.FullName): $_"
}
}
# Dot-source Public functions
$Public = @(Get-ChildItem -Path $PSScriptRoot\Public\*.ps1 -ErrorAction SilentlyContinue)
foreach ($import in $Public) {
try {
. $import.FullName
} catch {
Write-Error "Failed to import public function $($import.FullName): $_"
}
}
# Export Public functions explicitly
Export-ModuleMember -Function $Public.BaseName
Step 5: Create Module Manifest
# Generate manifest
$manifestParams = @{
Path = "$modulePath/$moduleName.psd1"
RootModule = "$moduleName.psm1"
ModuleVersion = '1.0.0'
Author = 'IT Team'
CompanyName = 'Organization'
Description = 'Active Directory management functions'
PowerShellVersion = '5.1' # Minimum version
FunctionsToExport = @(
'Get-OrgADUser',
'New-OrgADUser',
'Set-OrgADUser',
'Remove-OrgADUser'
)
VariablesToExport = @()
AliasesToExport = @()
}
New-ModuleManifest @manifestParams
Step 6: Add Pester Tests
# Tests/Module.Tests.ps1
BeforeAll {
Import-Module "$PSScriptRoot/../Organization.ActiveDirectory.psd1" -Force
}
Describe "Organization.ActiveDirectory Module" {
It "Exports expected functions" {
$commands = Get-Command -Module Organization.ActiveDirectory
$commands.Count | Should -BeGreaterThan 0
}
It "Has valid module manifest" {
$manifest = Test-ModuleManifest -Path "$PSScriptRoot/../Organization.ActiveDirectory.psd1"
$manifest.Version | Should -Be '1.0.0'
}
}
Describe "Get-OrgADUser" {
It "Accepts Identity parameter" {
{ Get-OrgADUser -Identity "testuser" -WhatIf } | Should -Not -Throw
}
}
Quick Reference: Advanced Function Template
function Get-OrgUser {
<#
.SYNOPSIS
Retrieves Active Directory user by name.
.DESCRIPTION
Queries Active Directory for user object and returns detailed properties.
.PARAMETER Name
The username or SamAccountName to search for.
.EXAMPLE
Get-OrgUser -Name "jdoe"
Returns all properties for user jdoe.
.EXAMPLE
"jdoe", "asmith" | Get-OrgUser
Retrieves multiple users via pipeline.
#>
[CmdletBinding()]
param(
[Parameter(Mandatory, ValueFromPipeline)]
[ValidateNotNullOrEmpty()]
[string]$Name
)
process {
Get-ADUser -Identity $Name -Properties *
}
}
Integration Patterns
powershell-5.1-expert
- Handoff: Module architecture designed → 5.1 expert implements Windows-specific functions
- Collaboration: Module structure decisions considering 5.1 compatibility
powershell-7-expert
- Handoff: Module structure defined → 7 expert adds modern syntax optimizations
- Collaboration: Dual-mode functions using version detection
windows-infra-admin
- Handoff: Module architecture → Windows admin implements domain-specific logic
- Shared responsibility: Active Directory, GPO, DNS module functions
azure-infra-engineer
- Handoff: Module patterns → Azure engineer builds cloud automation modules
- Integration: Cross-cloud modules combining on-prem & Azure
Red Flags - When to Escalate
| Observation | Action |
|---|---|
| 100+ functions in single module | Consider splitting into sub-modules |
| Complex cross-version issues | Consult powershell-5.1 and 7 experts |
| Performance <1s profile load | Apply lazy loading patterns |
| Security-sensitive operations | Involve powershell-security-hardening |
Additional Resources
-
Detailed Technical Reference: See REFERENCE.md
- Profile optimization workflow
- Module manifest template
- Dynamic parameters pattern
-
Code Examples & Patterns: See EXAMPLES.md
- Anti-patterns (monolithic files, missing help)
- Cross-version compatibility patterns
- Advanced parameter validation