Menu
Use after a design spec is written, before any implementation begins. Runs a structured assessment of holes, risks, pros/cons, system conflicts, overhead, and a go/no-go verdict. Must be completed before build handoff.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use when the user says 'set up a report', 'create a digest', 'I want a daily/weekly summary of', 'monitor X and report on Y', or any request for scheduled information synthesis. Produces a Conductor workflow + rules for scheduled reports and digests.
Use when the user says 'when X happens, do Y', 'set up a rule for', 'react to', or any request to define an event-driven trigger. Produces a Conductor reaction rule YAML and saves it to ~/pantheon/conductor/rules/.
Use when the user says 'set up a webhook', 'connect X service to Pantheon', 'receive notifications from Y', or any request to bring external events into the Pantheon. Produces a webhook integration config and rule, saved to ~/pantheon/conductor/webhooks/ and ~/pantheon/conductor/rules/.
Use when the user says 'set up a pipeline', 'create a workflow', 'I need a multi-god process', or any request to chain multiple gods into a repeatable sequence. Produces a Conductor workflow YAML and saves it to ~/pantheon/conductor/workflows/.
Conductor handoff and acknowledgement protocol for Pantheon gods
Use when the user says 'build Amber a skill', 'she needs something for X at the conference', 'make her a skill that does Y', 'package this up for her', 'design a skill for Amber', or any request to design, build, and ship a custom skill for Amber. The output is a fully packaged skill (zip file) ready to attach to Telegram and send to her agent for install. Designed to be invoked repeatedly as new conference needs come up.
| name | design-critical-assessment |
| description | Use after a design spec is written, before any implementation begins. Runs a structured assessment of holes, risks, pros/cons, system conflicts, overhead, and a go/no-go verdict. Must be completed before build handoff. |
| version | 1.0.0 |
| author | Thoth |
| license | MIT |
| metadata | {"hermes":{"tags":["design","assessment","risk","pre-flight","go-no-go"],"related_skills":["conductor-design-workflow","conductor-design-rule"]}} |
After a design spec is complete but before any code is written. The purpose is not to block progress — it's to catch problems while they're cheap to fix.
Walk through each section with the designer. Be honest. If something is a vulnerability, say so.
What does the design NOT address?
For each risk, assess:
| Risk | Likelihood (Low/Med/High) | Impact (Low/Med/High) | Mitigation |
|---|
Does this design overlap with or break existing systems?
| Existing System | Nature of Overlap | Resolution |
|---|
Check against:
What does this cost?
Honest list. Not a sales pitch.
| Pro | Con |
|---|
If the cons section is longer than the pros section, that's not automatically a no — but it means the justification needs to be stronger.
One of:
The verdict includes a summary statement addressed to the user: "Here's what I think we should do and why."
Write the assessment to the spec as an appendix section, or to the Athenaeum as a companion document. The assessment should be findable when someone asks "why did we build this this way?"
