القائمة
Review an application-type spec for completeness against UI rendering requirements and golden-path structure.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | spec-app-review |
| description | Review an application-type spec for completeness against UI rendering requirements and golden-path structure. |
Validate a component_type: application spec against what the spec-editor-ui actually renders and the structural requirements from specify.
spec/spec.md in the target repo. Verify component_type: application in frontmatter.The spec-editor-ui ApplicationDetailPage has 7 tabs. Each tab extracts data from specific sections/artifacts:
| Tab | Data Source |
|---|---|
| Overview | Purpose, In Scope, Out of Scope, Operational Boundaries, API Endpoints, Components (catalog), Standards (frontmatter) |
| Architecture | Mermaid diagrams (tagged logical/deployment), FR diagrams, Aggregated Objects (catalog) |
| Integration | Artifacts with tags: [integration] in frontmatter |
| Security | Trust Boundaries table, artifacts with tags: [security], Standards |
| Requirements | StR/US/FR/NFR tables parsed from spec.md |
| Decisions | ADR artifacts (type: ADR) or inline ADR sections |
| Spec | Raw markdown rendering |
These are the exact parser behaviors that determine whether content renders:
parseDelegations() only recognizes (Handled by X) or (Delegated to X) patterns. Other parentheticals won't extract delegation targets.parseBulletList() default pattern is bold-description (**Title** — Description). Plain bullets fall back to title-only.parseBulletList({ pattern: 'bold-colon' }) requires **Name**: detail format.parseTable() on section "Trust Boundaries" — expects 3 columns: Role, Capabilities, Restrictions.findDiagramByTag() matches %% @type: logical and %% @type: deployment comments in mermaid blocks.tags: [integration] in YAML frontmatter (case-insensitive).tags: [security] in YAML frontmatter.Use a known well-formed application spec in your org as a comparison reference when reviewing.
Convert ISO spec requirements (StR, FR, NFR) into a TDD-based project plan with dependency analysis, parallel execution tracks, quality gates, and task decomposition. Selects or starts a plan and writes a frontmatter-typed plan bundle under plan/<Plan-id>-<slug>/ (Plan + Task + index + log).
Create or update spec artifacts from a design or change request. Orchestrates authoring each requested requirement type (StR/US/FR/NFR/IT) as a discrete file using quoin catalog templates and Quire validation.
Analyze requirement statements (FR/NFR/StR) for EARS requirement-grammar conformance and author a SpecReview of the findings.
Build and maintain the requirements Test Matrix ensuring 100% coverage.
Review requirements for quality, consistency, and completeness.
Verify a targeted plan is complete and validated — every task done, the Test Matrix backed by real tracking tags in tests, and code fully traced to spec (flagging underspecified code with no owning requirement). Optional semantic review checks that intent↔test↔code actually agree. Emits a quire-validated SpecReview artifact to reviews/YY-MM-DD-<slug>.md.