القائمة
Use when the task is mostly clear (50-90%) with one or two open decisions that can likely be resolved by inspecting the repo — not fully bounded, not a blank-slate design problem
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use when the user provides a GitHub PR link with a "deep review" trigger inside a locally cloned repo, to perform a thorough multi-dimensional code review grounded in ARCS DAG context, AGENTS.md conventions, and optional codegraph coupling analysis, then post findings as inline GitHub review comments under explicit user gate
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Use when initializing a new ARCS project — bootstrapping a repo into the DAG with metadata, docs, and structural knowledge entries. Covers gather → present summary → init → codegraph ingestion → fan-out analysis across typed sub-agents.
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Use when implementing any feature or bugfix, before writing implementation code
Use when you have a spec or requirements for a multi-step task, before touching code
استنادا إلى تصنيف SOC المهني
| name | code-agent |
| description | Use when the task is mostly clear (50-90%) with one or two open decisions that can likely be resolved by inspecting the repo — not fully bounded, not a blank-slate design problem |
Task is mostly clear (50-90%) but 1-2 decisions remain open — resolvable by inspecting the repo.
flowchart TD
A[Orient: arcs brief --lean --json] --> K[Knowledge: arcs knowledge search slug keywords]
K --> B[Search: arcs search slug keywords]
B --> C[Inspect repo — patterns, types, fixtures]
C --> D{Confidence score >=80?}
D -->|Yes| E[Implement — TDD for new behavior]
D -->|No, inferable| E
D -->|No, genuine ambiguity| F[Ask ONE targeted question]
F --> E
E --> G[Verify — affected tests + lint on changed files]
G --> H{Complexity expanded?}
H -->|No| I[Done]
H -->|Yes| J[Pause — state issue — offer brainstorming]
Before investigating or implementing, check what the DAG already knows:
arcs knowledge search <slug> "<task-keywords>" --lean --json
Look for:
kind: pattern — existing conventions that apply to this changekind: gotcha — known traps in this areakind: lesson — prior learnings from similar workIf relevant entries exist, incorporate their guidance. Don't rediscover what's already known.
Phase 0 is read-only; close the loop on the way out. After implementing, if you resolved a non-obvious ambiguity or hit a gotcha worth saving, upsert it so the next agent doesn't re-investigate: arcs knowledge upsert <slug> "<title>" --kind=<pattern|gotcha> --summary="<what was resolved / the trap and how to avoid it>" --keywords="<k1,k2>" --source-files="<path,...>" --json. Skip when the work was mechanical and surfaced nothing non-obvious. Upsert is idempotent by title.
the-ladder during implementation — reach for stdlib / native / an installed dep before new code, and leave // SHORTCUT: markers for deliberate simplificationsquick-devbrainstorming