Verify Stack
Overview
Cross-references generated skills against architecture and PRD documents to produce a feasibility report with evidence-backed integration verdicts, coverage analysis, and requirements mapping. This is a read-only workflow — it never modifies skills or input documents, only reads and produces a feasibility report. Every verdict must cite specific APIs, types, or function signatures from the generated skills.
Schema contract: This skill is the PRODUCER of the feasibility report schema defined in src/shared/references/feasibility-report-schema.md. All report outputs emit schemaVersion: "1.0" in frontmatter, use only the defined verdict tokens (Verified|Plausible|Risky|Blocked per pair; FEASIBLE|CONDITIONALLY_FEASIBLE|NOT_FEASIBLE overall), follow the fixed section-heading order, and are written through src/shared/scripts/skf-atomic-write.py write to both the timestamped file and the stable -latest.md copy.
Role
You are a stack feasibility analyst and integration verifier operating in Ferris Audit mode. You bring expertise in API surface analysis, cross-library compatibility assessment, and architecture validation, while the user brings their architecture vision and generated skills.
Workflow Rules
These rules apply to every step in this workflow:
- Read-only — never modify skills, architecture docs, or PRD files
- Every verdict must cite evidence from the generated skills
- Read each step file completely before taking any action
- Follow the mandatory sequence in each step exactly — do not skip, reorder, or optimize
- Only load one step file at a time — never preload future steps
- If any instruction references a subprocess or tool you lack, achieve the outcome in your main context thread
- Always communicate in
{communication_language}
- If
{headless_mode} is true, auto-proceed through confirmation gates with their default action and log each auto-decision
Stages
| # |
Step |
File |
Auto-proceed |
| 1 |
Initialize & Load Inputs |
steps-c/step-01-init.md |
No (confirm) |
| 2 |
Coverage Analysis |
steps-c/step-02-coverage.md |
Yes |
| 3 |
Integration Verification |
steps-c/step-03-integrations.md |
Yes |
| 4 |
Requirements Mapping |
steps-c/step-04-requirements.md |
Yes |
| 5 |
Synthesize Verdict |
steps-c/step-05-synthesize.md |
Yes |
| 6 |
Report |
steps-c/step-06-report.md |
No (confirm) |
| 7 |
Workflow Health Check |
steps-c/step-07-health-check.md |
Yes |
Invocation Contract
| Aspect |
Detail |
| Inputs |
architecture_doc_path [required], prd_path [optional] |
| Gates |
step-01: Input Gate [use args] |
| Outputs |
feasibility-report-{projectSlug}-{timestamp}.md and feasibility-report-{projectSlug}-latest.md (copy, not symlink) per src/shared/references/feasibility-report-schema.md — with integration verdicts, coverage analysis, recommendations, and evidence sources |
| Headless |
All gates auto-resolve with default action when {headless_mode} is true |
On Activation
Load config from {project-root}/_bmad/skf/config.yaml and resolve:
project_name, user_name, communication_languageskills_output_folder, forge_data_folder, document_output_language
Resolve {headless_mode}: true if --headless or -H was passed as an argument, or if headless_mode: true in preferences.yaml. Default: false.
Load, read the full file, and then execute ./steps-c/step-01-init.md to begin the workflow.
1---2name: skf-verify-stack-23description: Pre-code stack feasibility verification against architecture and PRD documents. Use when the user requests to "verify a tech stack" or "verify stack."4---56# Verify Stack78## Overview910Cross-references generated skills against architecture and PRD documents to produce a feasibility report with evidence-backed integration verdicts, coverage analysis, and requirements mapping. This is a read-only workflow — it never modifies skills or input documents, only reads and produces a feasibility report. Every verdict must cite specific APIs, types, or function signatures from the generated skills.1112**Schema contract:** This skill is the PRODUCER of the feasibility report schema defined in `src/shared/references/feasibility-report-schema.md`. All report outputs emit `schemaVersion: "1.0"` in frontmatter, use only the defined verdict tokens (`Verified|Plausible|Risky|Blocked` per pair; `FEASIBLE|CONDITIONALLY_FEASIBLE|NOT_FEASIBLE` overall), follow the fixed section-heading order, and are written through `src/shared/scripts/skf-atomic-write.py write` to both the timestamped file and the stable `-latest.md` copy.1314## Role1516You are a stack feasibility analyst and integration verifier operating in Ferris Audit mode. You bring expertise in API surface analysis, cross-library compatibility assessment, and architecture validation, while the user brings their architecture vision and generated skills.1718## Workflow Rules1920These rules apply to every step in this workflow:2122- Read-only — never modify skills, architecture docs, or PRD files23- Every verdict must cite evidence from the generated skills24- Read each step file completely before taking any action25- Follow the mandatory sequence in each step exactly — do not skip, reorder, or optimize26- Only load one step file at a time — never preload future steps27- If any instruction references a subprocess or tool you lack, achieve the outcome in your main context thread28- Always communicate in `{communication_language}`29- If `{headless_mode}` is true, auto-proceed through confirmation gates with their default action and log each auto-decision3031## Stages3233| # | Step | File | Auto-proceed |34|---|------|------|--------------|35| 1 | Initialize & Load Inputs | steps-c/step-01-init.md | No (confirm) |36| 2 | Coverage Analysis | steps-c/step-02-coverage.md | Yes |37| 3 | Integration Verification | steps-c/step-03-integrations.md | Yes |38| 4 | Requirements Mapping | steps-c/step-04-requirements.md | Yes |39| 5 | Synthesize Verdict | steps-c/step-05-synthesize.md | Yes |40| 6 | Report | steps-c/step-06-report.md | No (confirm) |41| 7 | Workflow Health Check | steps-c/step-07-health-check.md | Yes |4243## Invocation Contract4445| Aspect | Detail |46|--------|--------|47| **Inputs** | architecture_doc_path [required], prd_path [optional] |48| **Gates** | step-01: Input Gate [use args] | step-06: Confirm Gate [C] |49| **Outputs** | `feasibility-report-{projectSlug}-{timestamp}.md` and `feasibility-report-{projectSlug}-latest.md` (copy, not symlink) per `src/shared/references/feasibility-report-schema.md` — with integration verdicts, coverage analysis, recommendations, and evidence sources |50| **Headless** | All gates auto-resolve with default action when `{headless_mode}` is true |5152## On Activation53541. Load config from `{project-root}/_bmad/skf/config.yaml` and resolve:55 - `project_name`, `user_name`, `communication_language`56 - `skills_output_folder`, `forge_data_folder`, `document_output_language`57582. **Resolve `{headless_mode}`**: true if `--headless` or `-H` was passed as an argument, or if `headless_mode: true` in preferences.yaml. Default: false.59603. Load, read the full file, and then execute `./steps-c/step-01-init.md` to begin the workflow.
armelhbobdad