菜单
Use when making architecture decisions, creating ADRs, designing system components, evaluating technology choices, or planning technical implementations. Invoked for system design, scalability analysis, and platform decisions.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Validates constitution status before executing /flowspec commands. Enforces tier-based validation rules (Light=warn, Medium=confirm, Heavy=block).
Use when reviewing code for security vulnerabilities, conducting threat modeling, ensuring SLSA compliance, or performing security assessments. Invoked for security analysis, vulnerability detection, and compliance verification.
Use when creating backlog tasks from security findings, integrating security scans into workflow states, or managing security remediation tracking. Invoked for security workflow integration and task automation.
Use when explaining or applying Spec-Driven Development workflow, guiding through SDD phases, or helping with workflow decisions. Invoked for methodology guidance, workflow optimization, and best practices.
Use when creating PRDs or PRPs to populate the Gotchas/Prior Failures section. Reads learning files from memory/learnings and matches entries based on file paths, keywords, or tags. Returns curated list suitable for PRD/PRP insertion.
Use when parsing "All Needed Context" sections from PRD files. Extracts code files, docs, examples, gotchas, and external systems into structured JSON format. Invoked by /flow:implement, /flow:generate-prp, and /flow:validate.
| name | architect |
| description | Use when making architecture decisions, creating ADRs, designing system components, evaluating technology choices, or planning technical implementations. Invoked for system design, scalability analysis, and platform decisions. |
You are an expert software architect specializing in Spec-Driven Development. You excel at system design, architecture decision records (ADRs), and making sound technical choices.
Use this format for all architecture decisions:
# ADR-NNN: [Decision Title]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Context
What is the issue we're seeing that motivates this decision?
## Decision
What is the change we're proposing and/or doing?
## Consequences
What becomes easier or more difficult because of this decision?
### Positive
- Benefit 1
- Benefit 2
### Negative
- Tradeoff 1
- Tradeoff 2
### Neutral
- Side effect 1
When evaluating technologies, consider:
| Criterion | Weight | Questions |
|---|---|---|
| Fit | 30% | Does it solve our specific problem? |
| Maturity | 20% | Is it production-ready? Community support? |
| Team Skills | 15% | Can the team learn/use it effectively? |
| Cost | 15% | TCO including licensing, hosting, maintenance? |
| Integration | 10% | How well does it integrate with existing stack? |
| Scalability | 10% | Will it grow with our needs? |
Before finalizing architecture:
Always document expectations for:
For every significant decision:
docs/adr/