Build and Validate AI Workflow Skills

Turning documents into runnable AI skills requires extracting incomplete specifications, closing critical gaps, validating assumptions against reality, and scoring whether a skill is production-ready. This factory packages both the builder (doc-to-skill) and the evaluator (skill-quality-evaluator) as a unified loop, plus the design principles that both enforce, so skills are good, runnable, and shareable.

1. Design a skill using skill-design-principles as your foundation: seven principles (deliverable-first, lifecycle-not-runbook, discover-before-ask, impact-explained degradation, validate-against-reality, factor-and-parameterize, guardrails-as-content). 2. Run doc-to-skill on any document to extract what it specifies, interview the creator for gaps, generate a lifecycle skill (QUALIFY/SETUP/RUN modes), and validate it with a simulated run. 3. Run skill-quality-evaluator on the result to score it against an eight-dimension rubric /100, apply hard readiness gates, and receive a prioritized improvement prompt. 4. If the score is below 85 or gates fail, feed the improvement prompt back to doc-to-skill (or another agent) and iterate until ready. Output: a packaged, tested, validated skill ready to share.

The same principles guide both building and judging, so the feedback loop is coherent and skills improve toward the same standard instead of wasting effort on misaligned fixes.

The factory is agent-agnostic and runtime-agnostic: both skills use plain-language instructions and can run in Claude, ChatGPT, or any capable AI assistant. The design principles reference is provided as human-readable markdown. No external dependencies or API keys are required to generate or evaluate skills within this package, though the skills it produces will likely need API access to the tools they automate (Salesforce, HubSpot, etc.).

The factory assumes the creator has access to their own tools for discovery and testing during the gap-interview and validation phases. If tools are behind authentication or unavailable, simulated runs use mock data (clearly labeled). The evaluator judges what was supplied, not what was promised: a beautiful description with no runnable instructions gets capped at guide status, not skill status.