메뉴
Validates a software product, service, or feature against readiness gates before advancing to the next delivery phase. Use when planning a phase transition or when the user mentions gate check, phase review, or readiness validation.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Turns real agent failures, repeated prompts, team-specific workflows, and durable project lessons into better SDD skills or memory entries. Use when the user asks to create/update/refine skills, extract reusable lessons, improve skill routing, encode team process, or save patterns for future sessions.
Provides the vendored agent-style v0.3.5 prose rule pack as a portable Claude skill. Use when installing, syncing, applying, or auditing SDD Agent-Style support in another project, or when a style-review workflow needs the bundled rules.
Reviews Markdown prose against the pinned agent-style v0.3.5 rules and optionally writes a polished copy beside the source. Use for specs, ADRs, PR bodies, release notes, and technical docs when prose quality or evidence discipline matters.
Scans Markdown (.md) files for malicious code injection including XSS, prompt injection, script injection, obfuscated payloads, and supply chain attack vectors. Use when auditing .md files for security threats or when the user mentions scanning markdown for malicious content.
Provides .NET and ASP.NET Core patterns for REST APIs, Entity Framework, dependency injection, and middleware. Use when working with C# files (*.cs, *.csproj) or when the user mentions .NET, ASP.NET Core, C#, or Entity Framework.
Designs hybrid cloud architectures connecting on-premises infrastructure with public cloud services. Use when designing systems spanning on-prem and cloud, or when the user mentions hybrid cloud or multi-environment architecture.
| name | gate-check |
| description | Validates a software product, service, or feature against readiness gates before advancing to the next delivery phase. Use when planning a phase transition or when the user mentions gate check, phase review, or readiness validation. |
| argument-hint | [target-phase: systems-design | technical-setup | pre-production | production | polish | release] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep, Bash, Write |
| effort | 3 |
| when_to_use | When validating software delivery readiness to advance to the next development phase |
This skill validates whether the software project is ready to advance to the next delivery phase. It checks for required artifacts, quality standards, and operational blockers.
Distinct from /project-stage-detect: That skill is diagnostic ("where are
we?"). This skill is prescriptive ("are we ready to advance?" with a formal
verdict).
The project progresses through these stages:
When a gate passes, write the new stage name to production/stage.txt
(single line, e.g. Production). This updates the status line immediately.
/gate-check production - validate readiness for that specific phase/project-stage-detect, then validate the NEXT phase transitionRequired Artifacts:
design/docs/product-concept.md exists and has contentdesign/docs/product-pillars.md)Quality Checks:
/design-review verdict not MAJOR REVISION NEEDED)Required Artifacts:
design/docs/systems-index.md with at least MVP systems enumerateddesign/docs/ (beyond product-concept.md and systems-index.md)Quality Checks:
Required Artifacts:
[CHOOSE]).claude/docs/technical-preferences.md populated)docs/architecture/Quality Checks:
Required Artifacts:
production/sprints/Quality Checks:
Required Artifacts:
src/ has active code organized into subsystemsdesign/docs/ with src/)tests/Quality Checks:
Bash)Required Artifacts:
src/)/release-checklist or /launch-checklist run)Quality Checks:
For each item in the target gate:
Glob and Read to verify files exist and have meaningful contentBash if a test runner is configuredRead the PRD and check for the 8 required sectionsRead technical-preferences.md and compare against any
profiling data in tests/performance/ or recent /perf-profile outputGrep for hardcoded strings in src/Read runbooks, release notes, deployment docs, and QA summaries if they existdesign/docs/ documents against src/ implementationsFor items that can't be automatically verified, ask the user:
/perf-profile or review recent monitoring data?"Never assume PASS for unverifiable items. Mark them as MANUAL CHECK NEEDED.
## Gate Check: [Current Phase] -> [Target Phase]
**Date**: [date]
**Checked by**: gate-check skill
### Required Artifacts: [X/Y present]
- [x] design/docs/product-concept.md - exists, 2.4KB
- [ ] docs/architecture/ - MISSING (no ADRs found)
- [x] production/sprints/ - exists, 1 sprint plan
### Quality Checks: [X/Y passing]
- [x] PRD has 8/8 required sections
- [ ] Tests - FAILED (3 failures in tests/unit/)
- [?] QA sign-off - MANUAL CHECK NEEDED
### Blockers
1. **No Architecture Decision Records** - Create an ADR before entering production.
2. **3 test failures** - Fix failing tests in tests/unit/ before advancing.
### Recommendations
- [Priority actions to resolve blockers]
- [Optional improvements that aren't blocking]
### Verdict: [PASS / CONCERNS / FAIL]
- **PASS**: All required artifacts present, all quality checks passing
- **CONCERNS**: Minor gaps exist but can be addressed during the next phase
- **FAIL**: Critical blockers must be resolved before advancing
When the verdict is PASS and the user confirms they want to advance:
production/stage.txt (single line, no trailing newline)Always ask before writing: "Gate passed. May I update production/stage.txt to 'Production'?"
production/stage.txt to '[new-stage]'?" - only on PASS + user confirmationDeliver exactly:
[Current Phase] -> [Target Phase]PASS / CONCERNS / FAILBased on the verdict, suggest specific next steps:
/brainstorm to create one/map-systems to decompose the concept into systems/reverse-document/architecture-decision-records/test-driven-development/release-checklist or /launch-checklist/perf-profile/security-audit/localize/launch-checklistThis skill follows the collaborative design principle:
Never block a user from advancing - the verdict is advisory. Document the risks and let the user decide whether to proceed despite concerns.