human-gate
Skill100 starsChanged 7 months agoMITView on GitHub
Pause execution and request human approval at defined checkpoints. Present summaries, state next steps, and record approval or rejection. Use at phase exits, after Gherkin generation, after implementation PR review, and after deployment verification.
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 11 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 32
When triggered: After Phase B2 (Spec-Enable) completes — PRD and all FRDs are approved.
- Distinctive: line 93
Ask the human to check applicable items and select a track
- Distinctive: line 94
If Hybrid is selected, ask which features (by FRD ID) are testable
- Distinctive: line 104
When triggered: After Track A completes green baseline execution for each feature (brownfield only).
- Distinctive: line 109
Test suite execution results (pass/fail counts, failures if any)
- Distinctive: line 130
When you reach a human gate:
- Distinctive: line 148
Wait: Do not proceed until the human responds.
- Distinctive: line 152
When the human approves:
- Distinctive: line 160
When the human rejects or provides feedback:
- Distinctive: line 162
Do not advance the phase
- Distinctive: line 165
When done, present for approval again
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Human Gate Protocol
Gate Locations
Human gates exist at these points:
- Phase 0 exit (shell setup approval)
- Phase 1a exit (FRD approval)
- Phase 1b exit (UI/UX approval)
- Phase 1c exit (increment plan approval)
- Phase 1d exit (tech stack resolution approval)
- Phase 2, Step 1 mid-point (Gherkin approval, per increment)
- Phase 2, Step 3 exit (implementation PR review, per increment)
- Phase 2, Step 4 exit (deployment verification, per increment)
- Phase B1 exit (extraction accuracy review — brownfield only)
- Phase B2a (PRD approval — brownfield only)
- Phase B2b (FRD approval — brownfield only)
- Phase B2c (spec refinement approval — brownfield only)
- Phase B3 entry (testability assessment — brownfield only)
- Green baseline verification (per feature after Track A baseline — brownfield only)
- Track B behavioral docs review (per feature — brownfield only)
- Path selection (choose modernize/rewrite/extend/etc. — brownfield only)
Testability Assessment Gate
Gate type: testability-assessment
When triggered: After Phase B2 (Spec-Enable) completes — PRD and all FRDs are approved.
What to Present
1. Extraction findings relevant to testability:
- Test discovery results — existing test frameworks, test count, coverage metrics
- Architecture overview — external dependencies, integration points, service boundaries
- Dev environment detection — Docker/compose files, env configs, local run scripts
2. Testability checklist for human to assess:
- Can the application be built and started locally (or in a dev environment)?
- Are external dependencies reachable, mockable, or fakeable?
- Can API endpoints be exercised (HTTP calls return responses)?
- Can the UI be rendered and interacted with (browser automation possible)?
- Is there a working dev/test environment configuration?
- Can the existing test suite (if any) be executed?
3. Decision options:
| Decision | Criteria | Next step |
| Track A (Full testability) | All or most checklist items checked | Proceed with green baseline |
| Track B (No testability) | Few or no items checked | Proceed with documentation-only |
| Hybrid | Some features testable, others not | Human identifies which features are testable |
For Hybrid, also collect: list of testable feature names mapped to FRD IDs.
What to Record
state.json — add to brownfield object:
{
"testability": "full | partial | none",
"track": "A | B | hybrid",
"testabilityChecklist": {
"canBuild": true,
"externalDepsReachable": true,
"apiExercisable": true,
"uiRenderable": false,
"devEnvExists": true,
"existingTestsRunnable": false
},
"featureTracks": {
"auth": "A",
"search": "A",
"reporting": "B"
}
}audit.log entry:
[ISO-timestamp] gate=testability-assessment decision={track} testability={level} result=approvedGate Flow
- Summarize extraction findings (test discovery, architecture, dev environment)
- Present the testability checklist
- Ask the human to check applicable items and select a track
- If Hybrid is selected, ask which features (by FRD ID) are testable
- Record the decision in
state.jsonandaudit.log - Advance to the appropriate track
Green Baseline Verification Gate
Gate type: green-baseline-verification
When triggered: After Track A completes green baseline execution for each feature (brownfield only).
What to Present
- Feature name and FRD ID
- Test suite execution results (pass/fail counts, failures if any)
- Baseline coverage summary
- Any tests that were skipped or could not run
Decision
- Accept baseline — Tests pass, proceed to increment delivery for this feature
- Reject baseline — Tests fail or coverage insufficient, iterate on baseline setup
- Reclassify feature — Move feature from Track A to Track B (not testable after all)
What to Record
audit.log entry:
[ISO-timestamp] gate=green-baseline-verification feature={frd-id} tests_passed={n} tests_failed={n} result={accepted|rejected|reclassified}How to Pause
When you reach a human gate:
- Summarize what was done. Present a concise summary:
- Phase 0: List all generated/verified files and scaffolding
- Phase 1a: List all FRDs with their key decisions
- Phase 1b: List screen map, design system, and prototype links per FRD
- Phase 1c: List the increment plan with ordering, scope, and dependencies
- Phase 1d: List tech stack decisions, infrastructure plan, created skills
- Step 1 (per increment): List Gherkin scenario counts, e2e flow coverage
- Step 3 (per increment): Link to the PR, list test results (pass/fail counts)
- Step 4 (per increment): Deployment URL, smoke test results, docs status
- Testability assessment (brownfield): Extraction findings, checklist, track recommendation
- Green baseline verification (brownfield): Test results, coverage, per-feature status
- State what's next. Tell the human what the next phase will do.
- Ask for approval. Explicitly ask: "Approve to proceed to Phase X, or provide feedback to iterate."
- Wait. Do not proceed until the human responds.
Recording Approval
When the human approves:
- Set
humanGates.<gate-name>totrueinstate.json - Log the approval in
audit.log - Advance
currentPhaseto the next phase - Continue the Ralph loop
On Rejection
When the human rejects or provides feedback:
- Log the rejection and feedback in
audit.log - Do not advance the phase
- Incorporate the feedback into the current phase
- Re-execute the relevant tasks with the feedback
- When done, present for approval again
Other versions1 project uses a version of this.
Word for word · 1
- crgarcia12/Liliput★ 4100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository47 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .github/copilot-instructions.mdCopilot instructions
- adrSkill
- api-extractorSkill
- architecture-mapperSkill
- aspireSkill
- audit-logSkill
- azure-deploymentSkill
- bug-fixSkill
- build-checkSkill
- cloud-native-assessmentSkill
- cloud-native-plannerSkill
- codebase-scannerSkill
- commit-protocolSkill
- contract-generationSkill
- data-model-extractorSkill
- ddd-modelingSkill
- dependency-inventorySkill
- deploy-diagnosticsSkill
- e2e-generationSkill
- error-handlingSkill
- extension-plannerSkill
- find-skillsSkill
- frd-generatorSkill
- gherkin-generationSkill
- implementationSkill
- modernization-assessmentSkill
- modernization-plannerSkill
- performance-assessmentSkill
- playwright-cliSkill
- prd-generatorSkill
- research-best-practicesSkill
- resumeSkill
- rewrite-assessmentSkill
- rewrite-plannerSkill
- security-assessmentSkill
- security-plannerSkill
- skill-creatorSkill
- skill-discoverySkill
- spec-refinementSkill
- spec-validatorSkill
- state-managementSkill
- tech-stack-resolutionSkill
- test-discoverySkill
- test-generationSkill
- test-runnerSkill
- ui-ux-designSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

