Skip to content
Open
Show file tree
Hide file tree
Changes from 14 commits
Commits
Show all changes
16 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions .archon/commands/design/design-brief.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
description: Convert an approved PRD into a design brief and UX handoff plan
argument-hint: <prd path or feature description>
---

# Design Brief

**Input**: $ARGUMENTS

---

## Mission

Create a design brief that gives implementation and QA enough context to build and validate the user experience.

## Process

1. Read `$ARTIFACTS_DIR/product/prd.md` if present.
2. Inspect existing UI patterns, components, routes, and accessibility conventions.
3. Identify required user flows, states, copy, errors, empty states, and permissions.
4. Write `$ARTIFACTS_DIR/design/design-brief.md`.

## Artifact Format

```markdown
# Design Brief

## UX Goal

## Primary User Flow

## Secondary Flows

## States

- Loading:
- Empty:
- Error:
- Permission denied:
- Success:

## Interaction Requirements

## Accessibility Requirements

## Existing Patterns To Reuse

## Open Design Questions

## Handoff Checklist
```

## Output

Return the artifact path and any design blockers.
42 changes: 42 additions & 0 deletions .archon/commands/design/design-handoff-check.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
description: Verify design handoff completeness before implementation proceeds
argument-hint: <feature or PRD path>
---

# Design Handoff Check

**Input**: $ARGUMENTS

---

## Mission

Confirm the design handoff is complete enough for implementation and QA.

## Process

1. Read the PRD and design brief artifacts.
2. Check for required flows, states, acceptance notes, copy, and accessibility expectations.
3. Write `$ARTIFACTS_DIR/design/handoff.md`.

## Artifact Format

```markdown
# Design Handoff

## Status

Ready / Ready with caveats / Blocked

## Required Implementation Notes

## Required QA Notes

## Missing Design Inputs

## Approval Recommendation
```

## Output

Return the handoff status and artifact path.
48 changes: 48 additions & 0 deletions .archon/commands/design/design-ui-review.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
description: Review a PR or implementation against design and UX expectations
argument-hint: <PR number, branch, or implementation summary>
---

# Design UI Review

**Input**: $ARGUMENTS

---

## Mission

Review the implementation for design consistency, accessibility, and user-flow quality.

## Process

1. Read `$ARTIFACTS_DIR/design/design-brief.md` and `$ARTIFACTS_DIR/development/implementation-report.md` if present.
2. Inspect changed UI files and any screenshots or validation artifacts.
3. Compare implementation against existing UI patterns.
4. Write `$ARTIFACTS_DIR/design/ux-review.md`.

## Artifact Format

```markdown
# UX Review

## Verdict

Pass / Pass with follow-ups / Blocked

## Findings

| Severity | Area | Finding | Required Action |
|----------|------|---------|-----------------|

## Accessibility Notes

## Visual Consistency Notes

## User Flow Notes

## Approval Recommendation
```

## Output

Return the verdict and artifact path.
50 changes: 50 additions & 0 deletions .archon/commands/development/development-confirm-plan.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
---
description: Confirm that an approved PRD or implementation plan is ready to build
argument-hint: <prd path, plan path, issue, or feature request>
---

# Development Confirm Plan

**Input**: $ARGUMENTS

---

## Mission

Confirm the implementation scope before code changes begin.

## Process

1. Read product, design, and security artifacts if present.
2. Inspect the repo for relevant files, APIs, tests, and patterns.
3. Identify the smallest safe implementation path.
4. Write `$ARTIFACTS_DIR/development/implementation-plan.md`.

## Artifact Format

```markdown
# Implementation Plan

## Scope

## Non-Scope

## Files And Modules

| Path | Action | Notes |
|------|--------|-------|

## Implementation Steps

## Validation Commands

## Risks

## Security Triggers

## Rollback Notes
```

## Output

Return the plan path and whether implementation is ready.
48 changes: 48 additions & 0 deletions .archon/commands/development/development-implementation-report.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
---
description: Summarize implementation results for downstream review
argument-hint: <implementation context>
---

# Development Implementation Report

**Input**: $ARGUMENTS

---

## Mission

Create an implementation report that downstream QA, security, docs, DevOps, and services workflows can consume.

## Process

1. Inspect git diff and commits.
2. Read validation output and PR metadata if available.
3. Write `$ARTIFACTS_DIR/development/implementation-report.md`.

## Artifact Format

```markdown
# Implementation Report

## Summary

## Changed Files

## Behavior Changes

## Validation Evidence

## Known Limitations

## Security-Relevant Changes

## QA Notes

## Docs Impact

## Rollback Notes
```

## Output

Return the report path and any downstream blockers.
46 changes: 46 additions & 0 deletions .archon/commands/devops/devops-deployment-readiness.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,46 @@
---
description: Review deployment readiness, operational risk, and production prerequisites
argument-hint: <release candidate, PR, or implementation report>
---

# DevOps Deployment Readiness

**Input**: $ARGUMENTS

---

## Mission

Determine whether the change is ready to deploy safely.

## Process

1. Read product, development, QA, security, and docs artifacts if present.
2. Inspect migrations, configuration, env vars, infrastructure, CI, release scripts, and rollback paths.
3. Write `$ARTIFACTS_DIR/devops/deployment-plan.md`.

## Artifact Format

```markdown
# Deployment Readiness

## Verdict

Ready / Ready with caveats / Blocked
Comment on lines +27 to +29
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

“Blocked” verdict isn’t actionable in the consuming workflow.

The artifact defines a Blocked verdict, but .archon/workflows/devops/release-readiness.yaml runs rollback-plan and devops-approval unconditionally after this node — there is no when:/trigger_rule gating on the verdict. As written, a Blocked outcome still progresses to rollback planning and approval, which dilutes the verdict’s meaning and risks deployments being approved despite known blockers.

Recommend either:

  • documenting in this command spec that on Blocked the command must fail (non-zero / explicit signal) so the workflow short-circuits, or
  • updating release-readiness.yaml to gate downstream nodes on $deployment-readiness.output.verdict.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In @.archon/commands/devops/devops-deployment-readiness.md around lines 27 - 29,
The "Blocked" verdict currently isn't gating downstream steps; update either the
command behavior or the workflow: modify the command represented by the verdict
(the output key "verdict") so that when it is "Blocked" the command exits
non-zero (failing the step), or update the workflow node(s) in
release-readiness.yaml that follow this task (the downstream jobs
"rollback-plan" and "devops-approval") to add a conditional check on
$deployment-readiness.output.verdict (e.g., a when/trigger_rule) so they only
run for allowed verdicts; pick one approach, implement the non-zero exit in the
command that emits "verdict" or add a when:/$deployment-readiness.output.verdict
gating to the rollback-plan and devops-approval nodes.


## Deployment Steps

## Required Config Or Secrets

## Migration Notes

## Monitoring And Alerts

## Rollback Readiness

## Blockers
```

## Output

Return the verdict and artifact path.
44 changes: 44 additions & 0 deletions .archon/commands/devops/devops-incident-followup.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,44 @@
---
description: Convert incident notes into remediation and runbook updates
argument-hint: <incident summary or link>
---

# DevOps Incident Follow-Up

**Input**: $ARGUMENTS

---

## Mission

Convert an incident into actionable remediation, runbook updates, and product follow-up.

## Process

1. Read incident notes from input.
2. Identify root cause, contributing factors, detection gaps, and prevention tasks.
3. Write `$ARTIFACTS_DIR/devops/incident-followup.md`.

## Artifact Format

```markdown
# Incident Follow-Up

## Summary

## Customer Impact

## Root Cause

## Detection And Response Gaps

## Remediation Tasks

## Runbook Updates

## Product Follow-Up
```

## Output

Return the artifact path and recommended issues to create.
42 changes: 42 additions & 0 deletions .archon/commands/devops/devops-rollback-plan.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
---
description: Generate a rollback plan for risky releases
argument-hint: <release candidate or PR>
---

# DevOps Rollback Plan

**Input**: $ARGUMENTS

---

## Mission

Create a concrete rollback plan for a risky release.

## Process

1. Read deployment, security, QA, and implementation artifacts.
2. Identify rollback commands, data migration constraints, monitoring signals, and ownership.
3. Write `$ARTIFACTS_DIR/devops/rollback-plan.md`.

## Artifact Format

```markdown
# Rollback Plan

## Rollback Trigger

## Fast Rollback Path

## Data Considerations

## Verification After Rollback

## Owner

## Communication Plan
```

## Output

Return the rollback plan path.
Loading