design-critical-assessment

星标15

分支2

更新时间2026年6月16日 03:19

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.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

来源

Duskript

Duskript/Pantheon

打开 GitHub 仓库查看创作者相关仓库

下载

Design Critical Assessment

When to Use

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.

Process

Walk through each section with the designer. Be honest. If something is a vulnerability, say so.

Step 1: Holes

What does the design NOT address?

Are there edge cases the spec doesn't cover?
Are there message types or event sources the user will eventually want that this design ignores?
Are there failure modes with no defined behavior? ("What happens when X crashes?")
Does the design assume something that isn't true yet? (e.g., "assumes NATS is running" when it isn't)

Step 2: Risks

For each risk, assess:

Risk	Likelihood (Low/Med/High)	Impact (Low/Med/High)	Mitigation

Single points of failure
Latency or performance regressions
Configuration drift over time
Security boundaries crossed accidentally
Escalation paths that silently drop
Scaling ceilings (queue backs up, too many events)

Step 3: System Conflicts

Does this design overlap with or break existing systems?

Existing System	Nature of Overlap	Resolution

Check against:

Pantheon RULES.md (Constitution)
Existing MCP servers and tools
Other gods' capabilities and domains
File paths and conventions in use
Hermes Agent features (kanban, cron, skills, etc.)
Ichor / Athenaeum / messaging
NATS/Subspace (if applicable)

Step 4: Overhead

What does this cost?

Cognitive overhead — does it make the user's mental model more complex?
Runtime overhead — CPU, RAM, latency, network traffic
Maintenance overhead — how many files to keep in sync? YAML drift?
Config overhead — how much setup before it works?
Debugging overhead — when it breaks, is it easy to find out why?

Step 5: Pros & Cons

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.

Step 6: Verdict

One of:

Go — build as designed
Go with constraints — build, but address specific items first (list them)
Go in phases — build incrementally, ship Layer 1 before Layer 2
No-go — don't build this. Here's why and what to do instead.

The verdict includes a summary statement addressed to the user: "Here's what I think we should do and why."

Step 7: Record

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?"

同仓库更多 Skills

同仓库

conductor-design-report

Duskript/Pantheon

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.

2026-06-1615

conductor-design-rule

Duskript/Pantheon

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/.

2026-06-1615

conductor-design-webhook

Duskript/Pantheon

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/.

2026-06-1615

conductor-design-workflow

Duskript/Pantheon

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/.

2026-06-1615

conductor-protocol

Duskript/Pantheon

Conductor handoff and acknowledgement protocol for Pantheon gods

2026-06-1615

skill-author-for-amber

Duskript/Pantheon

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.

2026-06-1615

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"]}}

Design Critical Assessment

When to Use

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.

Process

Walk through each section with the designer. Be honest. If something is a vulnerability, say so.

Step 1: Holes

What does the design NOT address?

Are there edge cases the spec doesn't cover?
Are there message types or event sources the user will eventually want that this design ignores?
Are there failure modes with no defined behavior? ("What happens when X crashes?")
Does the design assume something that isn't true yet? (e.g., "assumes NATS is running" when it isn't)

Step 2: Risks

For each risk, assess:

Risk	Likelihood (Low/Med/High)	Impact (Low/Med/High)	Mitigation

Single points of failure
Latency or performance regressions
Configuration drift over time
Security boundaries crossed accidentally
Escalation paths that silently drop
Scaling ceilings (queue backs up, too many events)

Step 3: System Conflicts

Does this design overlap with or break existing systems?

Existing System	Nature of Overlap	Resolution

Check against:

Pantheon RULES.md (Constitution)
Existing MCP servers and tools
Other gods' capabilities and domains
File paths and conventions in use
Hermes Agent features (kanban, cron, skills, etc.)
Ichor / Athenaeum / messaging
NATS/Subspace (if applicable)

Step 4: Overhead

What does this cost?

Cognitive overhead — does it make the user's mental model more complex?
Runtime overhead — CPU, RAM, latency, network traffic
Maintenance overhead — how many files to keep in sync? YAML drift?
Config overhead — how much setup before it works?
Debugging overhead — when it breaks, is it easy to find out why?

Step 5: Pros & Cons

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.

Step 6: Verdict

One of:

Go — build as designed
Go with constraints — build, but address specific items first (list them)
Go in phases — build incrementally, ship Layer 1 before Layer 2
No-go — don't build this. Here's why and what to do instead.

The verdict includes a summary statement addressed to the user: "Here's what I think we should do and why."

Step 7: Record

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?"