agentic-structure
Collaborative programming framework for production-ready development. Use when starting features, writing code, handling security/errors, adding comments, discussing requirements, or encountering knowledge gaps. Applies to all development tasks for clear, safe, maintainable code.
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o agentic-structure.zip https://jpskill.com/download/17423.zip && unzip -o agentic-structure.zip && rm agentic-structure.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17423.zip -OutFile "$d\agentic-structure.zip"; Expand-Archive "$d\agentic-structure.zip" -DestinationPath $d -Force; ri "$d\agentic-structure.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
agentic-structure.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
agentic-structureフォルダができる - 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-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Agentic Structure
Agentic Structure は、プログラミングをより効率的に行うために設計されたプロンプティングフレームワークです。
このガイドラインの核となるのは、ユーザーと共同でプロジェクトを作成し、コーディングを行うことです。 すべてを単独で計画し進めるのではなく、与えられたアイデアや意見に基づいて相互にフィードバックを行うことで、より良い結果を達成することを目標としています。 さらに、ドキュメントには、開発プロセス全体を通して参照すべき、良いプラクティスと悪いプラクティス、コードスタイル規則、およびライブラリの使用に関するガイドラインが含まれています。
Guideline Collection
これらは、必要に応じてプルする参照資料です。現在のタスクに関連するものだけを読んでください。すべてを事前に理解しておく必要はありません。
DEVELOPMENT_PROCESS.md - 明確で安全、本番環境に対応可能で、保守しやすい開発のための原則 DISCUSSION_GUIDELINES.md - 合意された決定に達するための議論を行う時期と方法 SECURITY_GUIDELINES.md - シークレット、ハッシュ、認証、および本番環境への公開に関する安全なデフォルト設定 CODING_STANDARDS.md - 明確さ、構造、再利用、および保守しやすい変更のためのコーディング規則 COMMENTING_GUIDELINES.md - 最小限で高シグナルのコメント規則とドキュメントの境界 ERROR_HANDLING.md - エラー処理の原則、境界、およびセキュリティを考慮した失敗 KNOWLEDGE_SHARING.md - 情報の不足を処理するための知識要求プロトコル
Guideline Selection Matrix
このマトリックスを使用して、現在のタスクで参照するガイドラインを決定してください。
| Your Task | Consult These Guidelines | When to Apply |
|---|---|---|
| Starting any feature implementation | DEVELOPMENT_PROCESS.md | Before writing any code - establishes workflow |
| User request is unclear or ambiguous | DISCUSSION_GUIDELINES.md | Cannot determine single correct interpretation |
| Need information beyond training data | KNOWLEDGE_SHARING.md | Require API docs, specs, or domain knowledge not in codebase |
| Writing or modifying functions/classes | CODING_STANDARDS.md | Creating or changing code structure |
| Deciding whether to add a comment | COMMENTING_GUIDELINES.md | About to write comment or user requests documentation |
| Implementing error handling | ERROR_HANDLING.md | Adding try-catch, error checking, or failure paths |
| Working with sensitive data or user input | SECURITY_GUIDELINES.md | Handling auth, secrets, file uploads, or external data |
| Multiple valid implementation approaches exist | DISCUSSION_GUIDELINES.md | Need to present options with trade-offs |
| Unsure about implementation scope | DEVELOPMENT_PROCESS.md | Need to determine what qualifies as "small step" |
| Code becoming deeply nested or complex | CODING_STANDARDS.md | Exceeding nesting limits or complexity thresholds |
| Error needs context or transformation | ERROR_HANDLING.md | Deciding how to handle caught exceptions |
Guideline Conflict Resolution
ガイドラインが矛盾するように見える場合は、次の優先順位で適用します。
1. SECURITY_GUIDELINES.md (Highest Priority)
- セキュリティは常に優先されます
- セキュリティに関するガイドラインが効率または簡潔さと矛盾する場合は、セキュリティを選択してください
- 例:SECURITY は、CODING_STANDARDS が不要なチェックを避けることを示唆している場合でも、入力検証を要求します
2. DEVELOPMENT_PROCESS.md
- プロセスの制約とコラボレーションの要件
- 例:CODING_STANDARDS が明確なアプローチを示唆している場合でも、些細な決定ではない場合は、ユーザーに確認する必要があります
3. ERROR_HANDLING.md
- 正確性と適切なエラー処理
- 例:CODING_STANDARDS がより単純なコードを示唆している場合でも、エラーを明示的に処理する必要があります
4. CODING_STANDARDS.md
- コードの品質と保守性に関する規則
- 例:ファイルの編成と命名規則
5. COMMENTING_GUIDELINES.md (Lowest Priority for Conflicts)
- ドキュメントのスタイルの好み
- 例:COMMENTING_GUIDELINES が推奨していない場合でも、セキュリティに関する仮定についてコメントを追加する場合があります
Conflict Resolution Example
CODING_STANDARDS が抽象化の作成を示唆しているが、ERROR_HANDLING が各レイヤーに明示的なエラー型を要求している場合は、ERROR_HANDLING に従ってください。つまり、コードが増えるとしても、明示的なエラー処理を作成します。
When No Conflict Exists
ほとんどのガイドラインは補完的です。関連するすべてのガイドラインをまとめて適用します。
- ワークフローには DEVELOPMENT_PROCESS を使用します
- ユーザーとのコミュニケーションには DISCUSSION_GUIDELINES を使用します
- コード構造には CODING_STANDARDS を使用します
- ドキュメントの決定には COMMENTING_GUIDELINES を使用します
- 失敗パスには ERROR_HANDLING を使用します
- 慎重な操作には SECURITY_GUIDELINES を使用します
- 情報が不足している場合は KNOWLEDGE_SHARING を使用します
各ガイドラインの詳細については、完全なドキュメントをお読みください。この Skill はクイックリファレンスを提供します。詳細なガイダンスが必要な場合は、完全なガイドラインを参照してください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Agentic Structure
Agentic Structure is a prompting framework designed to make programming more efficient.
The core of this guideline is to collaboratively create projects and code together with users. Rather than planning and proceeding with everything independently, the goal is to achieve better results through mutual feedback based on given ideas and opinions. Additionally, the documentation includes good and bad practices, code style rules, and library usage guidelines, which should be referenced throughout the development process.
Guideline Collection
These are pull-when-needed references - read only what's relevant to your current task; there is no expectation to consume everything upfront.
DEVELOPMENT_PROCESS.md - Principles for clear, safe, production-ready, maintainable development DISCUSSION_GUIDELINES.md - When and how to run discussions to reach aligned decisions SECURITY_GUIDELINES.md - Secure defaults for secrets, hashing, auth, and production exposure CODING_STANDARDS.md - Coding rules for clarity, structure, reuse, and maintainable change COMMENTING_GUIDELINES.md - Minimal, high-signal commenting rules and documentation boundaries ERROR_HANDLING.md - Error handling principles, boundaries, and security-minded failures KNOWLEDGE_SHARING.md - Knowledge request protocol for handling information gaps
Guideline Selection Matrix
Use this matrix to determine which guideline(s) to consult for your current task:
| Your Task | Consult These Guidelines | When to Apply |
|---|---|---|
| Starting any feature implementation | DEVELOPMENT_PROCESS.md | Before writing any code - establishes workflow |
| User request is unclear or ambiguous | DISCUSSION_GUIDELINES.md | Cannot determine single correct interpretation |
| Need information beyond training data | KNOWLEDGE_SHARING.md | Require API docs, specs, or domain knowledge not in codebase |
| Writing or modifying functions/classes | CODING_STANDARDS.md | Creating or changing code structure |
| Deciding whether to add a comment | COMMENTING_GUIDELINES.md | About to write comment or user requests documentation |
| Implementing error handling | ERROR_HANDLING.md | Adding try-catch, error checking, or failure paths |
| Working with sensitive data or user input | SECURITY_GUIDELINES.md | Handling auth, secrets, file uploads, or external data |
| Multiple valid implementation approaches exist | DISCUSSION_GUIDELINES.md | Need to present options with trade-offs |
| Unsure about implementation scope | DEVELOPMENT_PROCESS.md | Need to determine what qualifies as "small step" |
| Code becoming deeply nested or complex | CODING_STANDARDS.md | Exceeding nesting limits or complexity thresholds |
| Error needs context or transformation | ERROR_HANDLING.md | Deciding how to handle caught exceptions |
Guideline Conflict Resolution
When guidelines appear to conflict, apply in this priority order:
1. SECURITY_GUIDELINES.md (Highest Priority)
- Security always takes precedence
- If a security guideline conflicts with efficiency or simplicity, choose security
- Example: SECURITY requires input validation even if CODING_STANDARDS suggests avoiding unnecessary checks
2. DEVELOPMENT_PROCESS.md
- Process constraints and collaboration requirements
- Example: Must ask user before non-trivial decisions, even if CODING_STANDARDS suggests a clear approach
3. ERROR_HANDLING.md
- Correctness and proper failure handling
- Example: Must handle errors explicitly even if CODING_STANDARDS suggests simpler code
4. CODING_STANDARDS.md
- Code quality and maintainability rules
- Example: File organization and naming conventions
5. COMMENTING_GUIDELINES.md (Lowest Priority for Conflicts)
- Documentation style preferences
- Example: May add comments for security assumptions even if COMMENTING_GUIDELINES discourages them
Conflict Resolution Example
If CODING_STANDARDS suggests creating an abstraction but ERROR_HANDLING requires explicit error types for each layer, follow ERROR_HANDLING - create explicit error handling even if it means more code.
When No Conflict Exists
Most guidelines are complementary. Apply all relevant guidelines together:
- Use DEVELOPMENT_PROCESS for workflow
- Use DISCUSSION_GUIDELINES for user communication
- Use CODING_STANDARDS for code structure
- Use COMMENTING_GUIDELINES for documentation decisions
- Use ERROR_HANDLING for failure paths
- Use SECURITY_GUIDELINES for sensitive operations
- Use KNOWLEDGE_SHARING when information is missing
For complete details on each guideline, read the full document. This Skill provides quick reference - consult the full guidelines when detailed guidance is needed.