القائمة
Use before build, fix, debug, review, or docs implementation; converts prompts into structured intent JSON with goal, constraints, and routing.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use for project memory, decisions, handoffs, genome, knowledge index, changelog, and patterns that must persist across sessions.
Use for frontend, backend, mobile, debugging, security, or specialized engineering work that needs focused domain references and strict boundaries.
Use for prototype, MVP, fullstack feature, from-scratch feature, or multi-domain work that needs a SPEC.md before planning or implementation. Do not use for tiny one-file edits.
Use when code changes may require documentation updates; maps git diff to candidate docs without auto-editing documentation.
Use before completion, PR, deploy, handoff, or when verifying code changes. Runs advisory or blocking checks and reports evidence.
Use when the task involves reading, creating, or editing `.docx` documents, especially when formatting or layout fidelity matters; prefer `python-docx` plus the bundled `scripts/render_docx.py` for visual checks.
| name | codex-intent-context-analyzer |
| description | Use before build, fix, debug, review, or docs implementation; converts prompts into structured intent JSON with goal, constraints, and routing. |
| load_priority | always |
Parse user request into structured intent JSON (goal, constraints, complexity). Trigger Socratic Gate for complex or ambiguous scope. Suggest an agent route after classification. Wait for explicit confirmation before implementation. For large repos: read index files first, max 20 files deep-read per task.
$codex-intent-context-analyzer or $intent.Always return a fenced JSON block in conversation:
{
"intent": "build | fix | review | debug | docs | refactor | deploy | handoff | other",
"goal": "One-sentence description",
"pain_points": ["Problems extracted from the prompt"],
"constraints": ["Technical or business constraints"],
"missing_info": ["Information needed but not provided"],
"normalized_prompt": "Clean rewrite of the user request",
"complexity": "simple | complex",
"needs_confirmation": true,
"suggested_agent": "frontend-specialist | backend-specialist | security-auditor | debugger | test-engineer | devops-engineer | planner | scrum-master | null"
}
Keep every existing field exactly as-is. The only additive extension is suggested_agent.
After classifying intent, select the best primary agent from skills/.agents/ and announce it in conversation:
🤖 Routing to @[agent-name]...
| Intent | Primary Agent | Secondary |
|---|---|---|
| build (frontend) | frontend-specialist | test-engineer |
| build (backend) | backend-specialist | test-engineer |
| fix or debug | debugger | — |
| review or audit | security-auditor | — |
| deploy | devops-engineer | security-auditor |
| plan | planner | — |
| scrum | scrum-master | — |
intent enum unchanged. plan and scrum are routing overlays, not new required JSON intent literals.suggested_agent to null and continue with the normal clarification flow.After routing to an agent, the following discipline skills activate automatically through agent behavioral rules:
| Agent | Auto-Loads Discipline Skills |
|---|---|
debugger | codex-systematic-debugging ($root-cause) + codex-test-driven-development ($tdd) |
test-engineer | codex-test-driven-development ($tdd) |
frontend-specialist | codex-test-driven-development ($tdd) via implement mode |
backend-specialist | codex-test-driven-development ($tdd) via implement mode |
planner | codex-subagent-execution ($sdd) available for execution handoff |
For fix or debug intents: Systematic debugging (4-phase root cause) activates BEFORE any fix attempt.
For all build intents: TDD (RED-GREEN-REFACTOR) activates as a behavioral constraint during implementation.
Trigger Socratic Gate for complexity: complex or ambiguous scope.
Do NOT write any code, scaffold any project, or take any implementation
action until you have presented a design and the user has approved it.
This applies to EVERY project regardless of perceived simplicity.
Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
Ask questions one at a time — do not overwhelm with multiple questions per message.
Ask at least 3 questions covering:
Prefer multiple choice questions when possible — easier to answer than open-ended.
Format:
Before settling on a design, propose 2-3 approaches with trade-offs:
Scale each section to its complexity:
After presenting the design, run a quick self-check:
Fix issues inline. No need to re-review — just fix and move on.
needs_confirmation true by default.If intent is other, ask user to rephrase or choose one of:
build, fix, review, debug, docs, refactor, deploy, handoff.
--help first.For repositories with more than 50 files:
ARCHITECTURE.md, CODEBASE.md, README.md.main, index, app, server)package.json, tsconfig.json, pyproject.toml, etc.)