القائمة
GitHub conventions — branch naming, commit format, issue/PR templates, and safe issue/PR referencing in comments.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
MCP tool error response format — canonical error object, standard codes, retry semantics.
Run any question, idea, or decision through a council of 5 AI advisors who independently analyze it, peer-review each other anonymously, and synthesize a final verdict. Based on Karpathy's LLM Council methodology. MANDATORY TRIGGERS: 'council this', 'run the council', 'war room this', 'pressure-test this', 'stress-test this', 'debate this'. STRONG TRIGGERS (use when combined with a real decision or tradeoff): 'should I X or Y', 'which option', 'what would you do', 'is this the right move', 'validate this', 'get multiple perspectives', 'I can't decide', 'I'm torn between'. Do NOT trigger on simple yes/no questions, factual lookups, or casual 'should I' without a meaningful tradeoff (e.g. 'should I use markdown' is not a council question). DO trigger when the user presents a genuine decision with stakes, multiple options, and context that suggests they want it pressure-tested from multiple angles.
How agents, skills, and commands work in this project.
Documentation writing conventions — style, structure, tone, and quality standards.
CSS design system principles — token usage, semantic layering, mobile-first, component isolation.
Logging conventions — level usage, formatting style, structured output.
استنادا إلى تصنيف SOC المهني
| name | github-conventions |
| description | GitHub conventions — branch naming, commit format, issue/PR templates, and safe issue/PR referencing in comments. |
| when_to_use | Using gh CLI, creating commits, posting PR/issue comments, or referencing issues by number. |
| user-invocable | false |
CRITICAL: When referencing numbered items in comments or posts, avoid #<number> format — GitHub auto-links these to issues/PRs. Use "Item 1:", "Finding 1:", etc.
Feature branches: feature/<description> or feature/issue-<number>
Always check if a branch already exists for an issue before creating a new one.
For sub-issues of a larger feature, branch from the parent feature branch rather than main. Sub-issue work merges back into the parent feature branch, which eventually merges to main.
Conventional commits format: <type>: description
Types: feat:, fix:, docs:, style:, refactor:, test:, chore:
Optional scope: feat(frontend): description
Templates in .github/ISSUE_TEMPLATE/ — read them for section structure.
bugenhancementPR template at .github/PULL_REQUEST_TEMPLATE.md — read it for section structure.
Use Closes #<number> to link PRs to issues.
Plans are posted as issue comments and saved to .claude/workspace/. See plan-format.md for the recommended structure.