メニュー
Template management system for code boilerplates, feedback templates, scaffolding, and project optimization workflows. Use when creating templates, generating boilerplate files, or managing scaffolding.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/modu-ai/moai-adk --skill moai-workflow-templatesコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | moai-workflow-templates |
| description | Template management system for code boilerplates, feedback templates, scaffolding, and project optimization workflows. Use when creating templates, generating boilerplate files, or managing scaffolding. |
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Write, Edit, Grep, Glob, mcp__context7__resolve-library-id, mcp__context7__get-library-docs |
| user-invocable | false |
| metadata | {"version":"3.1.0","category":"workflow","status":"active","updated":"2026-01-11","modularized":"true","tags":"workflow, templates, boilerplate, scaffolding, optimization, feedback","aliases":"moai-workflow-templates","replaces":"moai-core-code-templates, moai-core-feedback-templates, moai-project-template-optimizer"} |
| progressive_disclosure | {"enabled":true,"level1_tokens":100,"level2_tokens":5000} |
| triggers | {"keywords":["template","boilerplate","scaffolding","code template","project template","feedback template","GitHub issue","template optimization"],"phases":["plan"],"agents":["manager-project","builder-skill"]} |
Unified template system combining code boilerplates, feedback templates, and project optimization workflows for rapid development and consistent patterns.
Core Capabilities:
When to Use:
Key Features:
Quick Access to Modules:
Pattern 1 - Template Structure:
Templates are organized in a directory hierarchy. The top-level templates directory contains framework-specific subdirectories. A backend framework directory such as fastapi-backend contains template.json for variables and a src directory with main.py, models subdirectory, and tests subdirectory. A frontend framework directory such as nextjs-frontend contains template.json, app directory, and components directory. A fullstack template contains separate backend and frontend subdirectories.
Pattern 2 - Template Variables:
Template variables are defined in a JSON configuration file with two main sections. The variables section defines key-value pairs such as PROJECT_NAME, AUTHOR, LICENSE, and PYTHON_VERSION. The files section maps file patterns to processing modes: files marked as substitute have variables replaced, while files marked as copy are transferred unchanged.
Pattern 3 - Template Generation:
The template generation process follows five steps. First, load the template directory structure. Second, substitute variables in files marked for substitution. Third, copy static files as-is. Fourth, run post-generation hooks such as dependency installation and git initialization. Fifth, validate the generated project structure.
Concept: Rapidly scaffold projects with production-ready boilerplates.
To generate a project, load the appropriate template such as backend/fastapi. Configure the scaffold with the project name, desired features such as auth, database, and celery, and customizations such as database type. Execute the scaffold to create the project structure.
For complete library and examples, see the Code Templates module documentation.
Concept: Structured templates for consistent GitHub issue creation.
Six Template Types: Bug Report, Feature Request, Improvement, Refactor, Documentation, and Question/Discussion.
Integration: Auto-triggered by the /moai:9-feedback command.
For all template types and usage, see the Feedback Templates module documentation.
Concept: Intelligently merge template updates while preserving user customizations.
Smart Merge Algorithm: The three-way merge process works as follows. First, extract user customizations from the backup. Second, get the latest template defaults from the current templates. Third, merge with appropriate priority where template_structure uses the latest defaults, user_config preserves user settings, and custom_content retains user modifications.
For complete workflow and examples, see the Template Optimizer module documentation.
Concept: Automatic backup management with intelligent restoration.
Restoration Process: The process follows four steps. First, load backup metadata using the backup identifier. Second, validate backup integrity and raise an error if the backup is corrupted. Third, extract customizations from the validated backup. Fourth, apply the extracted customizations to the current project.
For complete implementation, see the Template Optimizer module section on Restoration Process.
Concept: Track template versions and maintain update history.
Version Tracking: The template_optimization configuration section stores last_optimized timestamp, backup_version identifier, template_version number, and customizations_preserved list containing items like language, team_settings, and domains.
For complete implementation, see the Template Optimizer module section on Version Tracking.
Code Templates include FastAPI REST API template, React component template, Docker and CI/CD templates, and template variables with scaffolding patterns.
Feedback Templates include Bug Report template, Feature Request template, Improvement template, Refactor template, Documentation template, Question template, and integration with /moai:9-feedback command.
Template Optimizer includes 6-phase optimization workflow, smart merge algorithm, backup discovery and restoration, and version tracking with history.
For detailed patterns and implementation strategies, refer to the Code Templates Guide for complete template library, Feedback Templates for issue template reference, and Template Optimizer for optimization and merge strategies.
[HARD] Document all template default modifications before applying changes. WHY: Template defaults serve as the baseline for all projects and undocumented changes create confusion and inconsistency across teams. IMPACT: Without documentation, teams cannot understand why defaults deviate from standards, leading to maintenance issues and conflicting implementations.
[HARD] Create backups before executing template optimization workflows. WHY: Template optimization involves structural changes that may be difficult to reverse without a clean restoration point. IMPACT: Missing backups can result in permanent loss of user customizations, requiring manual reconstruction of project-specific configurations.
[HARD] Resolve all merge conflicts during template update workflows. WHY: Unresolved conflicts create broken configurations that prevent proper template functionality. IMPACT: Ignored conflicts lead to runtime errors, inconsistent behavior, and project instability requiring emergency fixes.
[SOFT] Maintain consistent template pattern usage throughout the project. WHY: Mixing different template patterns creates cognitive overhead and makes the codebase harder to understand and maintain. IMPACT: Inconsistent patterns reduce code predictability and increase onboarding time for new team members.
[HARD] Preserve complete customization history across all template updates. WHY: Customization history provides an audit trail of project-specific decisions and enables rollback to previous states. IMPACT: Lost history makes it impossible to understand why changes were made, preventing informed decisions about future modifications.
[HARD] Validate template functionality through testing before production deployment. WHY: Untested templates may contain errors that only surface in production environments, causing system failures. IMPACT: Production failures from untested templates result in downtime, data issues, and emergency rollbacks affecting users.
[SOFT] Design templates within reasonable complexity limits for maintainability. WHY: Excessive template complexity makes them difficult to understand, modify, and debug when issues arise. IMPACT: Overly complex templates slow down development velocity and increase the likelihood of errors during customization.
[HARD] Track template versions using the built-in version management system. WHY: Version tracking enables understanding of template evolution, compatibility checking, and coordinated updates. IMPACT: Without version tracking, teams cannot determine which template features are available or coordinate updates across projects safely.
Agents:
Skills:
Commands:
Project Initialization Workflow: Select code template using Pattern 1, scaffold project structure, apply customizations, and initialize version tracking using Pattern 5.
Feedback Submission Workflow: Execute /moai:9-feedback command, select issue type using Pattern 2, fill template fields, and auto-generate GitHub issue.
Template Update Workflow: Detect template version change, create backup using Pattern 4, run smart merge using Pattern 3, and update version history using Pattern 5.
Status: Production Ready (Enterprise) Modular Architecture: SKILL.md + 3 core modules Integration: Plan-Run-Sync workflow optimized Generated with: MoAI-ADK Skill Factory
| Rationalization | Reality |
|---|---|
| "I will add the template file directly to .claude/, not to internal/template/templates/" | Template-first rule is HARD. Local files are overwritten on moai update. Edit the template source. |
| "This template is only for our project, so language neutrality does not apply" | Templates ship to every moai init user across 16 supported languages. Neutrality is mandatory. |
| "make build is slow, I will just copy the file manually" | Manual copy diverges from embedded.go. The next moai update silently reverts the manual copy. |
| "The template variable is easier to hardcode than to parameterize" | Hardcoded paths break when the user is on a different OS or username. Use Go template variables or $HOME. |
| "I will skip the template and add a local-only override" | Local overrides are undocumented and non-portable. Prefer a template with conditional rendering. |
.claude/ or .moai/ without a corresponding file in internal/template/templates/.HomeDir used in fallback path inside a .sh.tmpl file.claude/, .moai/, .agency/ has a corresponding template sourcemake build succeeds after template changes (show build output).sh.tmpl files use $HOME for fallback paths, not .HomeDirdiff between local copy and template output shows no unexpected divergence