Menú
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 con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
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.
Basado en la clasificación ocupacional SOC
| 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?"
