v1.5.3: zero validation issues — all SKILL.md files under 4000 chars

- Trim all 13 SKILL.md files from 4200-4970 chars to 2520-3890 chars
- Fix TOC embedding: use full heading text from reference files
- Fix example detection: use Input:/Output: markers (not In:/Out:)
- Remove parent-traversal reference to docs/AGENT_OPERATIONS.md
- Fix blocker-handling-protocol.md TOC comment in progress-monitoring

Validation: 0 CRITICAL, 0 MAJOR, 0 MINOR, 0 NIT, 0 WARNING

Author: Emasoft

.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "ai-maestro-orchestrator-agent",
-  "version": "1.5.2",
+  "version": "1.5.3",
   "description": "Task distribution, agent coordination, progress monitoring - executes plans via subagents. Requires AI Maestro for inter-agent messaging.",
   "author": {
     "name": "Emasoft",

skills/amoa-checklist-compilation-patterns/SKILL.md

@@ -15,73 +15,58 @@ agent: amoa-main
 
 ## Overview
 
-Compiles verification checklists from project requirements: module, quality gate, test coverage, review, release, task assignment.
+Compiles verification checklists from project requirements.
 
 ## Prerequisites
 
-- Access to requirements documentation (USER_REQUIREMENTS.md or similar)
+- Access to USER_REQUIREMENTS.md
 
 ## Instructions
 
-1. Read the project requirements documentation
-2. Identify the checklist type needed (module, quality gate, review, test coverage, release, task)
-3. Consult the appropriate reference from Contents below
-4. Extract verification points, structure by logical groupings, and define acceptance criteria
-5. Add mandatory RULE 14 compliance section
-6. Apply the template from checklist-templates.md
-7. Review, write to project docs or GitHub issue, and report results
+1. Read requirements and identify checklist type needed
+2. Consult the appropriate reference from Contents below
+3. Extract verification points, structure by groups, define acceptance criteria
+4. Apply template from checklist-templates.md, append RULE 14 section, and output
 
 Copy this checklist and track your progress:
 
-- [ ] Read the project requirements documentation
-- [ ] Identify the checklist type needed
-- [ ] Consult the appropriate reference from Contents below
-- [ ] Extract verification points and define acceptance criteria
-- [ ] Add mandatory RULE 14 compliance section
-- [ ] Apply the template and review
+- [ ] Read requirements and identify checklist type
+- [ ] Extract verification points and define criteria
+- [ ] Apply template, append RULE 14 section
+- [ ] Write to project docs or GitHub issue
 
 ## Contents
 
-1. [checklist-types-reference.md](references/checklist-types-reference.md) - All 6 checklist types
+1. [checklist-types-reference.md](references/checklist-types-reference.md)
   <!-- TOC: Module Completion Checklists | Quality Gate Checklists | Review Checklists | Test Coverage Checklists | Release Readiness Checklists | Task Assignment Checklists | Checklist Type Selection Guide -->
-2. [checklist-templates.md](references/checklist-templates.md) - Templates
+2. [checklist-templates.md](references/checklist-templates.md)
   <!-- TOC: Standard Checklist Template | Priority-Annotated Checklist Template | Dependency-Ordered Checklist Template | Test Coverage Checklist Template -->
-3. [checklist-compilation-workflow.md](references/checklist-compilation-workflow.md) - 4-phase workflow
+3. [checklist-compilation-workflow.md](references/checklist-compilation-workflow.md)
   <!-- TOC: Phase 1: Requirements Gathering | Phase 2: Checklist Structuring | Phase 3: Format and Document | Phase 4: Quality Assurance | Step-by-Step Procedure -->
-4. [checklist-best-practices.md](references/checklist-best-practices.md) - Principles, pitfalls, maintenance
+4. [checklist-best-practices.md](references/checklist-best-practices.md)
   <!-- TOC: Checklist Design Principles | Common Pitfalls to Avoid | Checklist Maintenance -->
-5. [checklist-examples.md](references/checklist-examples.md) - Examples and walkthroughs
+5. [checklist-examples.md](references/checklist-examples.md)
   <!-- TOC: Complete Example: SVG Parser Quality Gate Checklist | Compilation Process Walkthrough | Orchestrator Interaction Example -->
-6. [skill-quick-reference.md](references/skill-quick-reference.md) - Quick reference, error handling
+6. [skill-quick-reference.md](references/skill-quick-reference.md)
   <!-- TOC: Inline Examples | Output Deliverables | Error Handling | Progress Tracking Checklist -->
 
-## RULE 14 Compliance
-
-Every checklist MUST append this section:
-```
-- [ ] USER_REQUIREMENTS.md exists and is current
-- [ ] All user requirements addressed
-- [ ] No technology substitutions without approval
-- [ ] No scope reductions without approval
-```
-
 ## Examples
 
-**Input:** "Compile a quality gate checklist for the auth-core module"
-**Output:** Checklist at `docs/checklists/auth-core-quality-gate.md` with grouped items, acceptance criteria, and RULE 14 section.
+**Input:** "Compile a quality gate checklist for auth-core"
+**Output:** Checklist at `docs/checklists/auth-core-quality-gate.md` with grouped items, criteria, RULE 14 section.
 
 See [checklist-examples.md](references/checklist-examples.md) for walkthroughs.
 <!-- TOC: Complete Example: SVG Parser Quality Gate Checklist | Compilation Process Walkthrough | Orchestrator Interaction Example -->
 
 ## Error Handling
 
-- **Missing requirements**: Halt, report `[ERROR] No USER_REQUIREMENTS.md found`
-- **Unresolvable criteria**: Flag ambiguous items, request clarification
-- **Incomplete modules**: Partial checklist with `[PENDING]` markers
+- Missing requirements: halt with `[ERROR] No USER_REQUIREMENTS.md found`
+- Ambiguous criteria: flag and request clarification
+- Incomplete modules: partial checklist with `[PENDING]` markers
 
 ## Output
 
-Markdown checklist with grouped items, acceptance criteria, and RULE 14 section.
+Markdown checklist with grouped items, criteria, and RULE 14 section.
 
 ## Resources
 

skills/amoa-developer-communication/SKILL.md

@@ -18,70 +18,62 @@ agent: amoa-main
 
 ## Overview
 
-This skill teaches effective communication with **human developers** across code reviews, issues, technical discussions, and status updates.
+Effective communication with human developers in code reviews, issues, and status updates.
 
 ## Prerequisites
 
-- Code review process familiarity
-- Access to communication channels (GitHub, Slack, etc.)
+Code review familiarity and access to communication channels.
 
 ## Output
 
-- **Communication Type** (String) — PR comment, issue response, explanation, status update
-- **Tone Assessment** (Pass/Fail) — Respectful, specific, constructive
-- **Blocking Status** — "Blocking" or "Non-blocking"
-- **Message Content** (Markdown) — The communication to send
-- **References** (URL list) — Links to relevant code, issues, docs
+Markdown message with communication type, tone assessment, blocking status, and reference links.
 
 ## Instructions
 
-1. **Identify the communication type** — PR comment, issue, explanation, status, or conflict.
-2. **Understand human-AI communication differences** — See: [references/key-principles.md](references/key-principles.md)
+1. **Identify type** — PR comment, issue, explanation, status, or conflict.
+2. **Review principles** in [references/key-principles.md](references/key-principles.md)
    <!-- TOC: Assume Good Intent | Be Specific, Not Vague | Separate Blocking from Non-Blocking | Acknowledge Good Work | Provide Context for Your Feedback -->
-3. **Use the decision tree** to select the right reference. See: [references/decision-tree.md](references/decision-tree.md)
+3. **Select reference** via [references/decision-tree.md](references/decision-tree.md)
    <!-- TOC: Decision Tree: Choosing Communication Type -->
-4. **Apply key principles** — Assume good intent, be specific, separate blocking/non-blocking.
-5. **Draft your message** following the relevant reference document patterns.
-6. **Run the pre-send checklist**. See: [references/tone-quick-reference.md](references/tone-quick-reference.md)
+4. **Draft message** following reference patterns.
+5. **Run pre-send checklist** from [references/tone-quick-reference.md](references/tone-quick-reference.md)
    <!-- TOC: Examples of Constructive Communication | Error Handling in Communication | Pre-Send Checklist -->
-7. **Send and monitor** for responses or follow-up needs.
+6. **Send and monitor** for follow-up.
 
 Copy this checklist and track your progress:
 
-- [ ] Identified communication type
-- [ ] Selected reference document via decision tree
+- [ ] Identified type and selected reference via decision tree
 - [ ] Applied key principles (good intent, specific, blocking status)
-- [ ] Drafted message following reference patterns
-- [ ] Passed pre-send checklist
+- [ ] Drafted message and passed pre-send checklist
 - [ ] Sent and monitoring for follow-up
 
 ---
 
 ## Error Handling
 
-Consult [references/conflict-resolution.md](references/conflict-resolution.md) for de-escalation
+See [references/conflict-resolution.md](references/conflict-resolution.md)
 <!-- TOC: Disagreeing Professionally | Offering Alternatives | Finding Compromise | Escalation Paths | When to Involve Maintainers -->
-and [references/tone-quick-reference.md](references/tone-quick-reference.md) for the pre-send checklist.
+and [references/tone-quick-reference.md](references/tone-quick-reference.md)
 <!-- TOC: Constructive Communication | Error Handling in Communication | Pre-Send Checklist -->
 
 ## Examples
 
 **Input:** PR uses unsafe string concatenation for SQL queries.
-**Output:** Non-blocking suggestion: "Consider parameterized queries to prevent SQL injection — e.g. `cursor.execute('SELECT * FROM users WHERE id = ?', (user_id,))`."
+**Output:** Non-blocking: "Consider parameterized queries — e.g. `cursor.execute('SELECT * FROM users WHERE id = ?', (user_id,))`."
 
-See `references/op-*.md` runbooks for more walkthroughs.
+See `references/op-*.md` for walkthroughs.
 
 ## Resources
 
-- [reference-catalog.md](references/reference-catalog.md) — Full reference catalog
+- [reference-catalog.md](references/reference-catalog.md)
   <!-- TOC: PR Comment Writing | Issue Communication | Technical Explanation | Conflict Resolution | Status Updates | Templates for Humans -->
-- [key-principles.md](references/key-principles.md) — Communication principles
+- [key-principles.md](references/key-principles.md)
   <!-- TOC: Assume Good Intent | Be Specific, Not Vague | Separate Blocking from Non-Blocking | Acknowledge Good Work | Provide Context -->
-- [decision-tree.md](references/decision-tree.md) — Communication type selection
+- [decision-tree.md](references/decision-tree.md)
   <!-- TOC: Decision Tree: Choosing Communication Type -->
-- [tone-quick-reference.md](references/tone-quick-reference.md) — Tone and pre-send checklist
+- [tone-quick-reference.md](references/tone-quick-reference.md)
   <!-- TOC: Constructive Communication | Error Handling in Communication | Pre-Send Checklist -->
 
 ## Script Output Rules
 
-Scripts MUST: write verbose output to `docs_dev/reports/`, emit only `[OK/ERROR] name - summary` + `Report: path` to stdout. Exception: `scripts/amoa_stop_check/` outputs JSON (hook requirement).
+Scripts write verbose output to `docs_dev/reports/`, emit `[OK/ERROR] name - summary` to stdout.

skills/amoa-github-action-integration/SKILL.md

@@ -15,103 +15,47 @@ user-invocable: false
 
 ## Overview
 
-Integrate Claude Code into GitHub Actions for automated PR reviews, @claude mention responses, and issue triage workflows.
+Set up Claude Code in GitHub Actions for PR reviews, @claude mentions, and issue triage.
 
 ## Prerequisites
 
-- GitHub repository with Actions enabled
-- Anthropic API key (ANTHROPIC_API_KEY secret)
-- Repository write permissions configured
-- Basic GitHub Actions knowledge
+GitHub repo with Actions enabled, Anthropic API key, and write permissions.
 
 ## Instructions
 
-1. Choose a workflow template from `templates/workflows/` (PR review, @claude mention, or issue triage)
-2. Copy the YAML file to `.github/workflows/`
-3. Add `ANTHROPIC_API_KEY` secret in Settings > Secrets and variables > Actions
-4. Enable "Read and write permissions" and "Allow GitHub Actions to create and approve pull requests" in Settings > Actions > General
-5. Customize model, tools, and prompts if needed
-6. Test on a draft PR or test issue, then monitor API costs
-
-## Trigger Conditions
-
-- User asks to "set up automated code review"
-- User wants "Claude to review PRs automatically"
-- User asks about "GitHub Actions with Claude"
-- User needs "@claude mention integration"
-- User wants "automated issue triage"
-
----
-
-## Template Details
-
-PR Review, @claude Mention Response, and Issue Triage templates in `templates/workflows/`.
-See: `references/template-details.md`
-<!-- TOC: PR Review Workflow | Mention Response Workflow | Issue Triage Workflow -->
-
-## Customization & Examples
-
-Model selection, tool restrictions, custom prompts, and YAML examples.
-See: `references/customization-and-examples.md`
-<!-- TOC: Changing the Model | Restricting Tools | Custom Prompts | Example 1: Basic PR Review Setup | Example 2: @claude Mention Handler -->
-
-## Error Handling
-
-Troubleshooting for workflow triggers, authentication, permissions, and timeouts.
-See: `references/error-handling.md`
-<!-- TOC: Workflow Not Triggering | Authentication Errors | Permission Denied Errors | Timeout Issues -->
-
----
-
-## Best Practices
-
-1. **Start with PR Review** - Most common and valuable integration
-2. **Use Sonnet for Speed** - Faster reviews, lower cost
-3. **Limit Tools** - Only allow necessary tools for security
-4. **Test on Draft PRs** - Test workflow before enabling widely
-5. **Monitor Costs** - Watch API usage with track_progress enabled
-
----
+1. Copy a template from `templates/workflows/` to `.github/workflows/`
+2. Add `ANTHROPIC_API_KEY` secret in repo Settings > Secrets
+3. Enable write permissions in Settings > Actions > General
+4. Customize model/tools if needed, then test on a draft PR
 
 ## Output
 
-| Field | Description |
-|-------|-------------|
-| Workflow File | YAML workflow in `.github/workflows/` |
-| API Key Secret | ANTHROPIC_API_KEY in repository settings |
-| Permissions | Read and write permissions enabled |
-| Status | Workflow enabled and ready to trigger |
-
----
+Workflow YAML in `.github/workflows/`, API key secret configured, permissions enabled.
 
 ## Checklist
 
 Copy this checklist and track your progress:
 
-- [ ] Select and copy workflow template to `.github/workflows/`
-- [ ] Add `ANTHROPIC_API_KEY` secret
-- [ ] Enable read/write permissions and PR creation for Actions
-- [ ] Customize model and tools if needed
-- [ ] Test on draft PR or test issue, then monitor costs
+- [ ] Copy workflow template to `.github/workflows/`
+- [ ] Add `ANTHROPIC_API_KEY` secret and enable write permissions
+- [ ] Test on draft PR or test issue
+- [ ] Monitor API costs
+
+## Error Handling
+
+See [error-handling.md](references/error-handling.md) for troubleshooting triggers, auth, permissions, and timeouts.
 
 ## Resources
 
 - [claude-code-action](https://github.com/anthropics/claude-code-action) | [GitHub Actions docs](https://docs.github.com/en/actions)
-- `references/template-details.md` - Workflow template specs
+- [template-details.md](references/template-details.md)
   <!-- TOC: PR Review Workflow | Mention Response Workflow | Issue Triage Workflow -->
-- `references/customization-and-examples.md` - Customization and YAML examples
+- [customization-and-examples.md](references/customization-and-examples.md)
   <!-- TOC: Changing the Model | Restricting Tools | Custom Prompts | Example 1: Basic PR Review Setup | Example 2: @claude Mention Handler -->
-- `references/error-handling.md` - Troubleshooting
+- [error-handling.md](references/error-handling.md)
   <!-- TOC: Workflow Not Triggering | Authentication Errors | Permission Denied Errors | Timeout Issues -->
 
 ## Examples
 
-**Input:** User asks "set up automated PR review with Claude"
-**Output:** Workflow `.github/workflows/claude-pr-review.yml` configured with secrets and permissions.
-
-See: `references/customization-and-examples.md`
-<!-- TOC: Changing the Model | Restricting Tools | Custom Prompts | Example 1: Basic PR Review Setup | Example 2: @claude Mention Handler -->
-
-## Script Output Rules
-
-Scripts write verbose output to `docs_dev/reports/` and emit only `[OK/ERROR] name - summary` on stdout. Scripts in `scripts/amoa_stop_check/` output JSON to stdout (hook requirement).
+**Input:** "set up automated PR review with Claude"
+**Output:** `.github/workflows/claude-pr-review.yml` with secrets and permissions configured.