بنقرة واحدة
project-landing
Decide when Patchmill may direct-land and when it must open a PR.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Decide when Patchmill may direct-land and when it must open a PR.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when executing Patchmill implementation plans that require one plan implementation subagent and final full-worktree readiness review before landing
Use when executing Patchmill implementation plans that require final full-worktree readiness review before landing
Use when executing Patchmill implementation plans with Superpowers task-level development plus final validation and pull-request readiness, without extra Codex or thermo-nuclear full-worktree reviews
Use when Patchmill run-once changes visible UI and needs committed reference screenshot evidence in the final pr-created JSON.
Use for Patchmill run-once spec and plan creation. Wraps sibling Superpowers brainstorming and writing-plans skills with Patchmill worktree, artifact path, and test-value policy.
Use when creating, editing, reviewing, or refactoring code modules to keep files focused, readable, and maintainable as code grows.
| name | project-landing |
| description | Decide when Patchmill may direct-land and when it must open a PR. |
Use this skill for the final direct-land versus pull-request decision.
Direct-land only when all of these are true:
If direct-land is eligible and Patchmill's prompt says direct landing is
allowed, squash-merge the implementation branch into the target branch, push the
target branch, close the source issue on the issue host, and return merged
final JSON. Include a landingDecision that explains why direct landing was
safe and confirms the issue was closed:
{
"status": "merged",
"branch": "agent/issue-123-fix-empty-state",
"mergeCommit": "<squash commit sha on target branch>",
"commits": ["<implementation commit sha>"],
"validation": ["npm test passed"],
"reviewSummary": "reviewed simple localized bug fix; closed issue #123",
"landingDecision": "direct squash-landed and closed issue: reproduced simple bug and validation passed"
}
For everything else, create or update a pull request and follow the configured
implementation skill's post-PR check readiness procedure. Do not return final
pr-created JSON immediately after creating the PR. Wait for observable
required checks; repair code-related test/lint/format/type-check/build failures
through the configured worker loop; and return an operator blocker for
cancelled, timed-out, infrastructure, permissions, quota, billing, or host
service failures. Return pr-created only after required checks pass. Prefer PR
fallback for visual UI changes, migrations, large refactors, dependency updates,
security-sensitive changes, and anything that needs human product, UX, or
architecture review. Include a landingDecision that explains why human review
is required:
{
"status": "pr-created",
"prUrl": "<pull request URL>",
"branch": "agent/issue-124-redesign-dashboard",
"commits": ["<implementation commit sha>"],
"validation": ["npm test passed", "npm run build passed"],
"reviewSummary": "reviewed implementation and visual evidence",
"landingDecision": "PR required: visible UI change needs human inspection"
}