تشغيل أي مهارة في Manus بنقرة واحدة

draft-procedural

النجوم٣٩

التفرعات١٧

آخر تحديث٣٠ يونيو ٢٠٢٦ في ١٩:١٢

Draft a new procedural documentation page or update an existing one. Use for task-oriented, step-by-step instructions that help a reader accomplish a specific goal. Examples include configuring an integration, creating an API key, or setting up an environment.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

warpdotdev

warpdotdev/docs

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

الكتّاب التقنيونالفنون والتصميم والترفيه والرياضة والإعلام·SOC 27-3042

SKILL.md

readonly

name	draft_procedural
description	Draft a new procedural documentation page or update an existing one. Use for task-oriented, step-by-step instructions that help a reader accomplish a specific goal. Examples include configuring an integration, creating an API key, or setting up an environment.

Draft procedural page

Draft a procedural documentation page with step-by-step instructions to accomplish a specific goal.

Workflow

Follow the workflow in .agents/skills/draft_docs/SKILL.md, using the procedural template at .agents/templates/procedural.md.

Content type rules

These rules are specific to procedural pages (from the "Drafting by content type" section of AGENTS.md):

Keep steps focused, not artificially atomic. Aim for one primary action per step, but group tightly related actions together when they share the same UI context. Up to ~3 related actions per step is acceptable.
Motivate steps before giving instructions. Briefly explain WHY before HOW, especially for setup steps.
Include expected outcomes after key steps so the reader can confirm they're on track.
Test all instructions for accuracy.
Provide troubleshooting for common failure points.
Don't over-explain — link to conceptual pages for the "why."
Title convention: gerund ("Configuring X", "Managing X")

AEO-driven procedures

If the request is driven by AEO, Peec, AI search prompts, answer-engine visibility, or search-query vocabulary, read .agents/skills/aeo_brief/SKILL.md before drafting. Use the brief to:

Translate source-data language into precise procedure titles, headings, and descriptions
Preserve accurate high-intent phrases without keyword stuffing
Decide whether the procedure belongs in a new page or as a tighter update to an existing page
Surface product or UI terminology questions before presenting the draft

Pre-handoff self-review

Before presenting the draft, check:

Scannability - Long procedure sections should use numbered steps, short bullets, or concise subsections. Do not leave dense paragraphs that hide actions.
Expected outcomes - Readers should know what success looks like after important steps.
UI accuracy - Product surfaces, buttons, settings paths, and command names should match the current product terminology.
Value over coverage - AEO-driven procedures should solve a real task, not collect loosely related keywords.
Open questions - Flag any steps that still need human product testing or UI verification.

Heading case

All headings (H1–H4) must use sentence case: capitalize only the first word and proper feature names.

✅ # Configuring environments
✅ ## Creating an API key
❌ # Configuring Environments
❌ ## Creating An API Key

Existing examples

Read 2-3 of these strong examples to match the existing pattern:

src/content/docs/reference/cli/api-keys.md
src/content/docs/platform/integrations/slack.md

المزيد من هذا المستودع

نفس المستودع

sync-error-docs

warpdotdev/docs

Detect new platform error codes in warp-server that are missing documentation pages in the docs repo. Creates doc pages, astro.config.mjs (sidebar config) entries, and redirects for any gaps. Use on a weekly schedule or when error codes change.

2026-07-1039

sync-openapi-spec

warpdotdev/docs

Sync the public Oz Agent API OpenAPI spec from warp-server into the docs repo, regenerating `developers/agent-api-openapi.yaml` (the file that powers the Scalar API reference at `docs.warp.dev/api`). Use when the warp-server public API has changed, when the Scalar reference looks stale, or on a scheduled cadence to keep the public API docs aligned with the canonical spec.

2026-07-1039

sync-terminology

warpdotdev/docs

Sync the Warp terminology glossary from the Notion Dictionary to the repo. Fetches the Notion Dictionary page, compares with .warp/references/terminology.md, and opens a PR for any additions or changes. Flags repo-only terms that are missing from Notion. Use on a weekly schedule or manually when terminology changes.

2026-07-1039

update-changelog

warpdotdev/docs

Update the public changelog at docs.warp.dev/changelog with the latest stable release. Fetches changelog data from channel-versions, formats a new entry, and opens a PR. Use after a stable release ships (typically Fridays).

2026-07-1039

afdocs-audit

warpdotdev/docs

Audit docs.warp.dev for agent-friendly documentation issues using the AFDocs scorecard. Checks llms.txt, markdown availability, content negotiation, page size, URL stability, and content structure. Use when asked to check agent readiness, run an AFDocs audit, improve the docs score, or verify llms.txt and markdown support.

2026-07-1039

release-updates

warpdotdev/docs

Run weekly release docs updates with standalone scripts for changelog, licenses, and telemetry, plus Linux/Oz Warp artifact preparation. Defaults to running all tasks in order, and supports running only selected tasks.

2026-07-0939

Draft procedural page

Draft a procedural documentation page with step-by-step instructions to accomplish a specific goal.

Workflow

Follow the workflow in .agents/skills/draft_docs/SKILL.md, using the procedural template at .agents/templates/procedural.md.

Content type rules

These rules are specific to procedural pages (from the "Drafting by content type" section of AGENTS.md):

Keep steps focused, not artificially atomic. Aim for one primary action per step, but group tightly related actions together when they share the same UI context. Up to ~3 related actions per step is acceptable.

Motivate steps before giving instructions. Briefly explain WHY before HOW, especially for setup steps.

Include expected outcomes after key steps so the reader can confirm they're on track.

Test all instructions for accuracy.

Provide troubleshooting for common failure points.

Don't over-explain — link to conceptual pages for the "why."

Title convention: gerund ("Configuring X", "Managing X")

AEO-driven procedures

If the request is driven by AEO, Peec, AI search prompts, answer-engine visibility, or search-query vocabulary, read .agents/skills/aeo_brief/SKILL.md before drafting. Use the brief to:

Translate source-data language into precise procedure titles, headings, and descriptions

Preserve accurate high-intent phrases without keyword stuffing

Decide whether the procedure belongs in a new page or as a tighter update to an existing page

Surface product or UI terminology questions before presenting the draft

Pre-handoff self-review

Before presenting the draft, check:

Scannability - Long procedure sections should use numbered steps, short bullets, or concise subsections. Do not leave dense paragraphs that hide actions.

Expected outcomes - Readers should know what success looks like after important steps.

UI accuracy - Product surfaces, buttons, settings paths, and command names should match the current product terminology.

Value over coverage - AEO-driven procedures should solve a real task, not collect loosely related keywords.

Open questions - Flag any steps that still need human product testing or UI verification.

Heading case

All headings (H1–H4) must use sentence case: capitalize only the first word and proper feature names.

✅ # Configuring environments

✅ ## Creating an API key

❌ # Configuring Environments

❌ ## Creating An API Key

Existing examples

Read 2-3 of these strong examples to match the existing pattern:

src/content/docs/reference/cli/api-keys.md

src/content/docs/platform/integrations/slack.md