القائمة
Use when updating project documentation after code changes — maps changed source files to relevant docs via aggregator indexes, then dispatches parallel agents to update each doc. Requires README.md aggregators with Key Files columns in each docs subdirectory.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when starting work on a Jira story — loads the ticket's context (summary, description, acceptance criteria, comments, attachments) into the conversation and downloads attachments by default. --delegate also writes a self-contained context doc for agent handoff. Trigger phrases: "bootstrap PROJ-123", "load jira ticket PROJ-123", "start work on PROJ-123", "jira-bootstrap PROJ-123".
Use when the user wants a structured, multi-session learning experience on a technical topic with persistent notes and progress tracking. Triggers include "let's learn X", "teach me X", "I want to study X", "I want to study/prepare for an interview on X", explicit /socratic-learning, "resume the learning session", or when CWD already contains an INDEX.md learning corpus and the user asks "what's next" or "continue".
Stricter variant of `/ensure-code-quality`: review every quality violation in the changes you introduced this session and fix them, with two extra teeth — the automated Python guard-clause checker runs in rule 8, and rule 6 (no in-function / mid-module imports) applies to `tests/` too, not just source. **Default scope:** only the lines you added — the `+` lines from `git diff` (staged and unstaged), plus the full contents of any untracked files you created. Pre-existing lines stay out of scope.
Use when about to claim a code change is complete or ready to commit in the current session, when wrapping up a coding task with edits to Python (or other) source files, or when the user explicitly invokes `/ensure-code-quality` (optional `extend` argument broadens scope to full touched files instead of just the lines Claude added).
Use when the user asks to create a git commit, commit current work, or prepare a commit from staged changes. Inspects the relevant diff, writes one commit message matching the repository convention, and runs git commit.
Use when bootstrapping a new project's documentation scaffolding, when running `/init` in a fresh repo that lacks `docs/roadmap/` or `docs/architecture/`, or when the user asks to "scaffold the project docs", "set up the roadmap structure", "init the doc folders". Creates `docs/roadmap/{README.md, phases.md}` and `docs/architecture/README.md` with self-documenting starter templates, then adds a thin pointer block to the project's `CLAUDE.md` (creating it if absent).
| name | upd-docs |
| description | Use when updating project documentation after code changes — maps changed source files to relevant docs via aggregator indexes, then dispatches parallel agents to update each doc. Requires README.md aggregators with Key Files columns in each docs subdirectory. |
Update project documentation based on code changes in a commit range.
Same commit range formats as /changelog:
v1.0.0..v1.1.0abc1234..HEAD or v1.0.0..HEAD~N or "last 20 commits"Each documentation subdirectory must have a README.md aggregator with a table containing a Key Files column that maps docs to source paths:
| Topic | Description | Key Files |
|-------|-------------|-----------|
| [Task Scoring](task-scoring.md) | ... | `src/features/tasks/selection_algorithms.py`, `priority_scorer.py` |
Discovery: scan docs/*/README.md for aggregators containing a table with a Key Files column.
Opt-in via aggregator: only directories whose README.md has a valid Key Files table are processed. All other docs/*/ subdirectories (plans, artifacts, etc.) are silently ignored — no warnings, no prompts.
If zero valid aggregators found: stop and tell the user:
"No aggregator README.md with Key Files mapping found in any
docs/*/directory. Create one manually or with/init-docsbefore running/upd-docs."
Do NOT proceed without aggregators — guessing file-to-doc mappings leads to missed or wrong updates.
git diff --stat <range> -- src/ → list of changed source filesgit diff --diff-filter=RADC --name-status <range> → detect renames (R), additions (A), deletions (D), and copies (C) across the entire repodocs/*/README.md aggregatorsrc/features/tasks/ matches src/features/tasks/selection_algorithms.py)src/ file doesn't match any existing Key Files entry, flag it as potentially unmappeddocs/*/ — flag for adding a row to the aggregatorShow the user a table of matched docs and aggregator changes before proceeding:
Docs to update (based on changed files in <range>):
docs/architecture/task-scoring.md — 5 files matched
docs/architecture/llm-pipeline.md — 3 files matched
docs/architecture/tool-filtering.md — 1 file matched
docs/app-usage/tasks.md — 2 files matched
Skipped (no matched files): 18 docs
Aggregator maintenance:
~ Key Files path update: src/old/path.py → src/new/path.py (in task-scoring.md row)
+ New source file not mapped: src/features/tasks/new_module.py
+ New doc needs aggregator row: docs/architecture/new-topic.md
- Deleted source file to remove: src/features/old_module.py (from tool-filtering.md row)
Proceed with all, or pick specific ones?
Wait for user confirmation. They may want to skip some or add others.
Dispatch up to 5 agents per batch. If more than 5 docs need updating, process in batches — wait for the current batch to complete before dispatching the next. This avoids API rate limits and keeps resource usage manageable.
For each confirmed doc, dispatch a parallel agent (use the Agent tool with multiple calls in one message). Each agent receives:
git diff <range> -- <matched files>)After updating individual docs, apply the aggregator maintenance flagged in Step 2:
Key Files path maintenance:
Doc file maintenance:
docs/*/ → add a row to the appropriate aggregator (Topic, Description, Key Files)Content maintenance:
Present all aggregator changes to the user for confirmation before applying.