القائمة
Update repo documentation (flow, app map, architecture, README, module docs) so it matches current code. Use when docs are stale and need to be reconciled with the codebase.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Ask which skill or flow fits your situation. A router over the skills in this repo.
Implement a piece of work based on a spec or set of tickets.
Configure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.
Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.
Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, published to the configured tracker — edges as text in one file per ticket locally, or native blocking links on a real tracker.
Plan a huge chunk of work — more than one agent session can hold — as a shared map of investigation tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.
| name | update-docs |
| description | Update repo documentation (flow, app map, architecture, README, module docs) so it matches current code. Use when docs are stale and need to be reconciled with the codebase. |
Edit repo docs that explain how code works (flow docs, app/module maps, architecture overviews, README, module-local markdown). Surgical edits, not rewrites.
Infer or ask for the target doc. Prefer existing docs over new ones:
README.md.If the doc does not exist, ask via AskUserQuestion before creating. Never invent a new doc location silently.
Read the target fully via Read before editing. Also read nearby related docs (neighbouring flow docs, app/architecture docs, README, module-local docs). Match the existing style, structure, vocabulary, and detail level.
Inspect the code the doc describes. Update from code reality, not guesses. Check entrypoints, main functions/classes, data flow, state changes, side effects, deps, error/fallback paths, files involved.
Unverifiable claims → remove or move to an Open questions section. Never present guesses as facts.
Default to small edits via Edit: keep useful sections, update stale ones, add missing flows, remove false claims, preserve heading style and tone. Rewrite the whole file via Write only if it is too stale to salvage; if so, say why before editing.
If it fits the doc's style, add or update at the bottom:
## Freshness
Last checked against code: YYYY-MM-DD
Relevant files checked:
- `path/to/file.py`
- `path/to/other_file.py`
Use today's date. Include only files actually inspected.
After editing: re-read via Read, confirm referenced paths exist, every major claim maps to code or a cited doc, no stale contradiction with nearby docs. Summarise the change.
Recommend one: /zoo-explore (still unclear), /zoo-feature (plan emerged), /zoo-refactor (tangled-but-working code), /zoo-fix (bug found), /zoo-commit-and-document (done). Do not auto-run.
COMPLETION PROTOCOL: Your final text message is your return value. Output this summary, then STOP — do not call any more tools.
Before broad reads, locate relevant files/symbols with Glob, Grep, or targeted file reads.
Prefer targeted Read with line ranges or block reads once the relevant area is known.
Read full files only when structure, ordering, or surrounding context is required for correctness.
Do not re-read unchanged files; use prior findings unless the file changed.