القائمة
Shared agent context — work attribution, safety rules, and development principles. Loaded by all plugin agents via skills: frontmatter.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
wipnote orchestration patterns for AI-assisted development. Use when working on code in an wipnote project — provides delegation patterns, model selection, quality gates, and work tracking guidance. Activate when planning work, delegating to agents, debugging, building features, or managing tasks.
Plan development work using a triage-gated, blocks-first interview. Classify scope as trivial/standard/complex, then run 0/3/4 staged interview rounds through the current harness native ask-user tool when available, or plain conversation when it is not. Each stage elicits the VISUAL block first (file-tree, api-endpoint, data-model, wireframe/diagram) and derives the prose slice fields (what/why/done_when) from it — blocks are authored inline as the YAML is built, not in a post-pass. Produces slice-card YAML with grounded visual blocks and visible research provenance for external claims; pauses for human review; promotes approved slices to features. Use when asked to plan, create a development plan, or build a feature with design clarity first.
SECONDARY enrichment path — add or revise structured visual blocks (data-model, api-endpoint, file-tree, wireframe, diagram, tabs) on an EXISTING wipnote plan. Use for legacy plans drafted before blocks-first existed, or for ad-hoc later block additions/revisions — NOT for primary planning. New plans get blocks authored inline during the wipnote:plan interview (blocks-first); only reach for this skill when a plan already exists and needs blocks added or changed after the fact. Reads the live block catalog from wipnote plan blocks, adds grounded blocks to slices, regenerates the plan HTML, and links to the dashboard.
Generate a grounded visual recap for a work item, git range, or session. Runs wipnote recap to produce a self-contained HTML artifact grounded in the real diff, reads the artifact, writes an outcome narrative (secrets redacted), and links to the dashboard recap URL. Use when asked to recap, summarize, or visualize completed work.
استنادا إلى تصنيف SOC المهني
| name | agent-context |
| description | Shared agent context — work attribution, safety rules, and development principles. Loaded by all plugin agents via skills: frontmatter. |
The orchestrator always provides the work item ID in your task prompt (e.g., "Feature: feat-580dc00b"). Use it:
wipnote feature start <id> # or bug start / spike start
Rules:
start on it — do NOT create a new onewipnote relevant "<topic>" before creating anything — it searches ALL items including completed tracks, plans, and features (the CIGS roster shows only open items; an empty roster does NOT mean no lineage exists). Attach to the best existing lineage (plan, track, or completed feature's track) if any covers the scope; only create a new item if none does. This applies equally to bugs, features, and spikes.When your task is done and quality gates pass:
wipnote feature complete <id> (or bug complete, spike complete)FORBIDDEN: Never edit .wipnote/ files directly. Use the CLI:
wipnote feature complete <id> not Edit(".wipnote/features/...")wipnote bug create "title" --track <trk-id> not Write(".wipnote/bugs/...")Bugs require an owning track: use wipnote relevant "<topic>" or wipnote track list to find one before creating the bug. --standalone is supported for feature creation only, not bug creation.
BATCH wipnote CLI calls. Each Bash tool call spends one turn from the user's quota. Chain commands with && into a single invocation whenever possible. Do this (1 call):
wipnote bug create "A" --track trk-xxx && \
wipnote bug create "B" --track trk-xxx && \
wipnote link add feat-aaa bug-new --rel caused_by
Never 3 separate Bash calls for the same thing. Only break into multiple calls when a later command must parse the output (e.g., a returned ID) of an earlier one.
Plan YAML files (.wipnote/plans/*.yaml) are validated assets — never write them directly.
Use the CLI to ensure valid structure:
wipnote plan create-yaml "<title>"wipnote plan rewrite-yaml <plan-id> --file /tmp/updated.yamlwipnote plan validate-yaml <plan-id>The rewrite-yaml command validates schema, checks meta.id match, and writes atomically.
Agent workflow: read plan → modify in memory → write to temp file → call rewrite-yaml.
At the start of your session, inject relevant architectural memory by running:
wipnote who --json 2>/dev/null | python3 -c "
import json,sys
d=json.load(sys.stdin)
wi=d.get('work_item','')
if wi: print(wi)
" 2>/dev/null
If the above prints a work item ID (e.g. feat-abc12345), run:
wipnote arch resolve --for <work-item-id> 2>/dev/null
Paste the output verbatim under a ## Architectural Context heading in your working context.
If the command prints "No arch cards matched." or fails silently, skip the heading — do not
emit errors or warnings. This step is informational only and must never block attribution or
task execution.
Drift markers (UNVERIFIED:) in the output mean the card's verified commit pre-dates recent
changes to covered files. Treat those facts as advisory — verify assumptions in code before
relying on them.
Web search is an integral part of software development, not a last resort. Route by role and by where the answer actually lives:
gh search issues, gh api) FIRST, or in parallel with local search. Official docs, GitHub issues, releases, and changelogs are first-class research.web.* use is limited to explicit user direct-browse requests, high-priority one-shot verification when no sidecar is available, or narrow confirmation after sidecar failure.Web/docs/GitHub searches COUNT as research — don't reflexively fall back to local grep for questions whose answer lives upstream, and don't let orchestrator-mode research consume the main context when a sidecar is available.
Subagents are routinely truncated mid-final-report. Guard against this by persisting substance into durable artifacts BEFORE composing the final message.
Persist first:
| What | Command |
|---|---|
| Diagnoses / root-cause findings | wipnote bug set-description <id> "<text>" or wipnote feature set-description <id> "<text>" |
| Progress steps | wipnote <type> add-step <id> "<step>" |
| Durable architectural facts | wipnote arch add <slug> --kind <kind> --body "…" --created-by <agent> |
| Code changes | git commit — only when your task includes committing AND quality gates pass; otherwise record the working-tree state via add-step and leave changes uncommitted |
Then summarize: The final message to the orchestrator is a compact summary pointing at those artifacts — not a dump of every detail. If truncation hits, it loses presentation, never substance.
On long tasks (>30 tool calls): Write findings into the work item incrementally
via add-step and set-description rather than holding everything for the end.
Capability delivery tiers: CLI via Bash (≈zero cost) > Skill > deferred MCP tool > eager MCP tool (avoid). Never expose wipnote's own commands as eager MCP tools. MCP is for external services only, with deferred loading.
Plugin/project boundary: wipnote must never author or overwrite AGENTS.md, CLAUDE.md, or GEMINI.md. Those are user-owned project files. Read and respect them; never silently own them.
These principles are language-neutral and apply to any codebase.