القائمة
Project git flow (branches, PR/MR, position check before dev). Use when starting or finishing a dev, branching, opening a PR/MR, merging, or to know which branch to work from.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Runs the project's agentic tests — by default the current sub-issue's Feature Path (FP), or the full suite of Happy Paths (HP) when "HP"/"all" is requested or when on an integration branch with an open MR. Use when running agentic tests, validating a sub-issue before auto-merge, or running the HP suite before an integration→develop PR.
Entry point of the skeleton. Sets up the agentic software factory in this repo — wires the two backlogs (business + technical), the triage vocabulary, and the domain docs for the engineering skills, scaffolds CONTEXT.md / docs/adr/, then kicks off the design phase (grilling). Run this first, in a fresh repo as well as an existing project.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.
Turn the current conversation context into a PRD and publish it to the project issue tracker. Use when user wants to create a PRD from the current context.
| name | git-flow |
| description | Project git flow (branches, PR/MR, position check before dev). Use when starting or finishing a dev, branching, opening a PR/MR, merging, or to know which branch to work from. |
Simplified vanilla git flow. This documents project usage, not git itself.
Business / technical backlogs: see docs/agents/business-backlog.md and
docs/agents/issue-tracker.md (source of truth for the tooling).
main: prod, protected; no direct merge (hotfix excepted).develop: global integration; every dev branches from it and merges back into it.integration/<business-ref>-<slug>: integration branch for one business user story, from up-to-date develop. Named after the business user story (its reference + a slug), because grill-with-docs creates it during grilling — before /to-prd generates the PRD on the technical backlog (so NOT the PRD number). The session writes its grilling output (CONTEXT.md, ADRs) here; the integration branch then accumulates the sub-issues. ready-for-agent sub-issues auto-merge into it after a green local check (build + tests + green Feature Path (FP)); integration -> develop stays a human decision (where the HP suite is run).feature/<issue-ref>-<slug>: one dev = one branch, from up-to-date develop — or from the integration/* of the business story when the dev implements a sub-issue of a grilled story.hotfix/<slug>: from main, on explicit request, PR + manual validation, then ported back onto develop.release branch until there's a pre-prod.We speak of MR/PR (depending on the technical backlog, see docs/agents/issue-tracker.md). On the git side:
New dev: from up-to-date develop -> feature/<issue-ref>-<slug>; or, if the dev implements a sub-issue of a grilled business story, from integration/* -> feature/<issue-ref>-<slug>. Unless stated otherwise, it ties to one or more business stories (-> technical issues); if none is known, ask.
Business story (integration branch): grill-with-docs creates integration/<business-ref>-<slug> from up-to-date develop (named after the business story, before /to-prd) and writes its grilling output there. /to-prd then creates the PRD, then /to-issues pushes the integration branch and creates the sub-issues based on it. ready-for-agent sub-issues PR -> integration/* and auto-merge once the local check is green (project build + tests + the FP green via /agentic-tests, no blocking finding). Keep the integration branch in sync with develop (it is long-lived).
No CI wired by default in the skeleton: the auto-merge gate is the agent running build + tests + the FP locally and merging only if everything is green. An agentic test needs an agent to drive the app: the day a CI exists, it doesn't run the test itself, it triggers an agent — and then it holds the gate.
End of dev: PR toward the branch the dev started from (--base develop, or --base <integration/*> for a sub-issue), assigning the responsible reviewer (<reviewer to define>); comment the PR link on the business story (moved to "in review"). The agent never merges into develop/main: the responsible human validates and merges. Only exception: the auto-merge of a ready-for-agent sub-issue into its integration/* (green local check).
integration/* -> develop: human decision. Before the PR, the agent runs the HP suite (/agentic-tests HP) and pastes the result into the PR (pass/fail + findings); if the feature warrants it, it proposes co-creating an HP — at most 3 HP (otherwise: merge two journeys, drop a non-critical one, or graft drive-by). The PR lists the included issues for a readable batch review. The agent opens the PR and gives the link; never merges.
develop -> main: human decision. On request, the agent opens the PR and gives the link; never merges.
On the 1st act of dev (code meant to be committed):
git rev-parse --abbrev-ref HEAD # where am I?
git branch --merged develop # already-merged branch = stale
git status -sb # upstream 'gone' = stale; clean tree?
On main, on a stale branch, or on a feature/* unrelated to the requested dev: don't pile on. Explain the cleanest placement (back to up-to-date develop + a new branch) and why, then ask for approval before acting (especially if there are uncommitted changes).