{ "schemaVersion": "1.0", "item": { "slug": "ogt-docs-define", "name": "OGT Docs Define", "source": "tencent", "type": "skill", "category": "效率提升", "sourceUrl": "https://clawhub.ai/EduardoU24/ogt-docs-define", "canonicalUrl": "https://clawhub.ai/EduardoU24/ogt-docs-define", "targetPlatform": "OpenClaw" }, "install": { "downloadMode": "redirect", "downloadUrl": "/downloads/ogt-docs-define", "sourceDownloadUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=ogt-docs-define", "sourcePlatform": "tencent", "targetPlatform": "OpenClaw", "installMethod": "Manual import", "extraction": "Extract archive", "prerequisites": [ "OpenClaw" ], "packageFormat": "ZIP package", "includedAssets": [ "SKILL.md" ], "primaryDoc": "SKILL.md", "quickSetup": [ "Download the package from Yavira.", "Extract the archive and review SKILL.md first.", "Import or place the package into your OpenClaw setup." ], "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "sourceHealth": { "source": "tencent", "status": "healthy", "reason": "direct_download_ok", "recommendedAction": "download", "checkedAt": "2026-04-23T16:43:11.935Z", "expiresAt": "2026-04-30T16:43:11.935Z", "httpStatus": 200, "finalUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentType": "application/zip", "probeMethod": "head", "details": { "probeUrl": "https://wry-manatee-359.convex.site/api/v1/download?slug=4claw-imageboard", "contentDisposition": "attachment; filename=\"4claw-imageboard-1.0.1.zip\"", "redirectLocation": null, "bodySnippet": null }, "scope": "source", "summary": "Source download looks usable.", "detail": "Yavira can redirect you to the upstream package for this source.", "primaryActionLabel": "Download for OpenClaw", "primaryActionHref": "/downloads/ogt-docs-define" }, "validation": { "installChecklist": [ "Use the Yavira download entry.", "Review SKILL.md after the package is downloaded.", "Confirm the extracted package contains the expected setup assets." ], "postInstallChecks": [ "Confirm the extracted package includes the expected docs or setup files.", "Validate the skill or prompts are available in your target agent workspace.", "Capture any manual follow-up steps the agent could not complete." ] }, "downloadPageUrl": "https://openagent3.xyz/downloads/ogt-docs-define", "agentPageUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent", "manifestUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent.json", "briefUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent.md" }, "agentAssist": { "summary": "Hand the extracted package to your coding agent with a concrete install brief instead of figuring it out manually.", "steps": [ "Download the package from Yavira.", "Extract it into a folder your agent can access.", "Paste one of the prompts below and point your agent at the extracted folder." ], "prompts": [ { "label": "New install", "body": "I downloaded a skill package from Yavira. Read SKILL.md from the extracted folder and install it by following the included instructions. Tell me what you changed and call out any manual steps you could not complete." }, { "label": "Upgrade existing", "body": "I downloaded an updated skill package from Yavira. Read SKILL.md from the extracted folder, compare it with my current installation, and upgrade it while preserving any custom configuration unless the package docs explicitly say otherwise. Summarize what changed and any follow-up checks I should run." } ] }, "documentation": { "source": "clawhub", "primaryDoc": "SKILL.md", "sections": [ { "title": "OGT Docs - Define", "body": "Guide for creating definition documents that establish WHAT things ARE in your system." }, { "title": "Philosophy", "body": "Definitions are the foundation of shared understanding.\n\nBefore anyone can implement, market, or discuss something, there must be a clear, agreed-upon definition of what it IS.\n\n┌─────────────────────────────────────────────────────────────────┐\n│ THE DEFINITION PRINCIPLE │\n├─────────────────────────────────────────────────────────────────┤\n│ A definition answers: │\n│ • WHAT is this thing? │\n│ • WHY does it exist? │\n│ • WHAT are its boundaries? (what it is NOT) │\n│ • HOW does it relate to other things? │\n│ │\n│ A definition does NOT specify: │\n│ • HOW to implement it (that's rules/) │\n│ • WHAT to do with it (that's todo/) │\n└─────────────────────────────────────────────────────────────────┘" }, { "title": "When to Use This Skill", "body": "Use ogt-docs-define when you need to:\n\nUnderstand the definitions folder structure\nChoose the right definition sub-skill\nCreate a definition that doesn't fit specialized categories\n\nFor specific definition types, use:\n\nTypeSub-SkillUse WhenBusiness conceptsogt-docs-define-businessPricing, users, revenue, marketProduct featuresogt-docs-define-featureNew capabilities, user-facing featuresTechnical architectureogt-docs-define-codeServices, data models, APIsMarketing conceptsogt-docs-define-marketingMessaging, positioning, audienceBrand identityogt-docs-define-brandingVisual identity, tone, guidelinesDeveloper toolsogt-docs-define-toolsCLI, scripts, dev workflows" }, { "title": "Folder Structure", "body": "docs/definitions/\n├── business/ # Business model and operations\n│ ├── pricing_model/\n│ │ ├── definition.md\n│ │ ├── tiers.md\n│ │ ├── limits.md\n│ │ └── .approved_by_founder\n│ ├── user_types/\n│ ├── revenue_model/\n│ └── market_position/\n│\n├── features/ # Product features\n│ ├── global_search/\n│ │ ├── feature.md\n│ │ ├── mvp.md\n│ │ ├── phase_0.md\n│ │ ├── phase_1.md\n│ │ ├── nice_to_have.md\n│ │ └── .version\n│ ├── user_auth/\n│ └── campaign_manager/\n│\n├── technical/ # Architecture and systems\n│ ├── service_layer/\n│ │ ├── definition.md\n│ │ ├── contracts.md\n│ │ ├── patterns.md\n│ │ └── .version\n│ ├── data_model/\n│ └── api_design/\n│\n├── domain/ # Domain-specific concepts\n│ ├── creatures/\n│ ├── abilities/\n│ └── campaigns/\n│\n├── marketing/ # Marketing and communications\n│ ├── value_proposition/\n│ ├── target_audience/\n│ └── messaging/\n│\n├── branding/ # Brand identity\n│ ├── visual_identity/\n│ ├── tone_of_voice/\n│ └── brand_guidelines/\n│\n└── tools/ # Developer tooling\n ├── cli/\n ├── scripts/\n └── workflows/" }, { "title": "The Folder-as-Entity Pattern", "body": "Every definition is a folder containing:\n\n{definition_slug}/\n├── {type}.md # Primary definition file\n├── {aspect}.md # Additional aspects/details\n├── {related}.md # Related concepts\n└── .{signals} # Status and metadata" }, { "title": "Primary File Naming", "body": "Definition TypePrimary FileBusinessdefinition.mdFeaturefeature.mdTechnicaldefinition.mdDomaindefinition.mdMarketingdefinition.mdBrandingdefinition.mdToolsdefinition.md" }, { "title": "Definition Lifecycle", "body": "flowchart LR\n subgraph lifecycle [\"Definition Lifecycle\"]\n D[draft] --> R[review]\n R --> A[approved]\n R --> REJ[rejected]\n REJ --> D\n A --> DEP[deprecated]\n end\n\n style D fill:#fef3c7\n style R fill:#e0e7ff\n style A fill:#d1fae5\n style REJ fill:#fecaca\n style DEP fill:#e5e7eb" }, { "title": "Draft State", "body": "Definition is being written, not yet ready for review.\n\n{definition_slug}/\n├── definition.md\n├── .version\n└── .draft # Empty signal: still in draft" }, { "title": "Review State", "body": "Definition is complete and awaiting approval.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .ready_for_review # Empty signal\n└── .review_requested_at # Timestamp" }, { "title": "Approved State", "body": "Definition is approved and can be referenced/implemented.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .approved # Empty signal\n├── .approved_by_{name} # Who approved\n└── .approved_at # When approved" }, { "title": "Rejected State", "body": "Definition was rejected, needs rework.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .rejected # Empty signal\n├── .rejected_reason # Why rejected\n└── .rejected_at # When rejected" }, { "title": "Deprecated State", "body": "Definition is outdated, replaced by something else.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .deprecated # Empty signal\n├── .deprecated_reason # Why deprecated\n├── .deprecated_at # When deprecated\n└── .superseded_by # What replaces it" }, { "title": "Creating a Definition: The Process", "body": "flowchart TD\n A[Need to define something] --> B{What type?}\n B -->|Business| C[ogt-docs-define-business]\n B -->|Feature| D[ogt-docs-define-feature]\n B -->|Technical| E[ogt-docs-define-code]\n B -->|Marketing| F[ogt-docs-define-marketing]\n B -->|Brand| G[ogt-docs-define-branding]\n B -->|Tools| H[ogt-docs-define-tools]\n B -->|Other| I[Use this skill]\n\n I --> J[Ask clarifying questions]\n J --> K[Draft definition]\n K --> L[Request review]\n L --> M{Approved?}\n M -->|Yes| N[Mark approved]\n M -->|No| O[Address feedback]\n O --> K" }, { "title": "Step 1: Ask Clarifying Questions", "body": "Before writing any definition, gather information:\n\nCore Questions (always ask):\n\nWhat is the name/identifier for this concept?\nIn one sentence, what IS it?\nWhy does it need to exist? What problem does it solve?\nWhat is it NOT? (boundaries)\nWhat other concepts does it relate to?\n\nContext Questions (ask as relevant): 6. Who are the stakeholders? 7. Are there existing similar concepts? 8. What decisions led to this concept? 9. What are the success criteria?" }, { "title": "Step 2: Draft the Definition", "body": "Use the appropriate template based on type (see sub-skills).\n\nGeneric Definition Template:\n\n# Definition: {Name}\n\n## Overview\n\nOne paragraph explaining what this is and why it exists.\n\n## Core Concept\n\nDetailed explanation of the concept.\n\n### Key Characteristics\n\n- Characteristic 1\n- Characteristic 2\n- Characteristic 3\n\n### Boundaries\n\nWhat this is NOT:\n\n- Not X\n- Not Y\n- Not Z\n\n## Relationships\n\nHow this relates to other concepts.\n\n| Related Concept | Relationship |\n| --------------- | -------------------------- |\n| Concept A | Uses/Contains/Depends on |\n| Concept B | Parallel to/Alternative to |\n\n## Examples\n\nConcrete examples that illustrate the concept.\n\n### Example 1: {Name}\n\nDescription of example.\n\n### Example 2: {Name}\n\nDescription of example.\n\n## Open Questions\n\nUnresolved questions that need future discussion.\n\n- Question 1?\n- Question 2?" }, { "title": "Step 3: Add Signal Files", "body": "# Create version file\necho '{\"schema\": \"1.0\", \"created\": \"'$(date -Iseconds)'\"}' > .version\n\n# Mark as draft\ntouch .draft" }, { "title": "Step 4: Request Review", "body": "# Remove draft signal\nrm .draft\n\n# Add review signals\ntouch .ready_for_review\necho \"$(date -Iseconds)\" > .review_requested_at" }, { "title": "Step 5: Handle Review Outcome", "body": "If Approved:\n\nrm .ready_for_review .review_requested_at\ntouch .approved\ntouch .approved_by_{reviewer_name}\necho \"$(date -Iseconds)\" > .approved_at\n\nIf Rejected:\n\nrm .ready_for_review .review_requested_at\ntouch .rejected\necho \"Reason for rejection\" > .rejected_reason\necho \"$(date -Iseconds)\" > .rejected_at\n# Then address feedback and restart from Step 2" }, { "title": "Status Signals (empty files)", "body": "SignalMeaning.draftStill being written.ready_for_reviewReady for review.approvedApproved for use.rejectedRejected, needs rework.deprecatedNo longer current" }, { "title": "Attribution Signals (empty files)", "body": "SignalMeaning.approved_by_{name}Who approved.created_by_{name}Who created.reviewed_by_{name}Who reviewed" }, { "title": "Content Signals (contain text)", "body": "SignalContent.versionJSON: {\"schema\": \"1.0\", \"created\": \"...\"}.rejected_reasonWhy rejected.deprecated_reasonWhy deprecated.superseded_byPath to replacement definition.review_requested_atISO timestamp.approved_atISO timestamp.rejected_atISO timestamp.deprecated_atISO timestamp" }, { "title": "Referencing Definitions", "body": "When other documents reference a definition:\n\nSee [Definition: User Types](docs/definitions/business/user_types/)\nPer the [Service Layer Definition](docs/definitions/technical/service_layer/)\n\nWhen code implements a definition, add a comment:\n\n/**\n * Implements: docs/definitions/technical/service_layer/\n * @see definition.md for contracts\n */\nexport class UserService implements IService {\n // ...\n}" }, { "title": "Common Mistakes", "body": "MistakeWhy It's WrongCorrect ApproachMixing definition with rulesConflates WHAT with HOWKeep definition pure, put HOW in rules/No boundaries sectionUnclear scope leads to scope creepAlways define what it is NOTSkipping reviewUnvalidated definitions cause misalignmentAlways get approvalEditing approved definitionsBreaks referencesCreate new version or deprecateNo relationships sectionIsolated definitions miss connectionsMap relationships explicitlyToo abstractCan't be implementedInclude concrete examplesToo specificCan't adapt to changeKeep at concept level" }, { "title": "Quality Checklist", "body": "Before requesting review, verify:\n\nOverview explains WHAT and WHY in one paragraph\n Core concept is detailed enough to understand\n Boundaries clearly state what this is NOT\n Relationships map to other definitions\n At least 2 concrete examples provided\n Open questions listed (if any)\n .version file created\n .draft signal present (will be removed when requesting review)" } ], "body": "OGT Docs - Define\n\nGuide for creating definition documents that establish WHAT things ARE in your system.\n\nPhilosophy\n\nDefinitions are the foundation of shared understanding.\n\nBefore anyone can implement, market, or discuss something, there must be a clear, agreed-upon definition of what it IS.\n\n┌─────────────────────────────────────────────────────────────────┐\n│ THE DEFINITION PRINCIPLE │\n├─────────────────────────────────────────────────────────────────┤\n│ A definition answers: │\n│ • WHAT is this thing? │\n│ • WHY does it exist? │\n│ • WHAT are its boundaries? (what it is NOT) │\n│ • HOW does it relate to other things? │\n│ │\n│ A definition does NOT specify: │\n│ • HOW to implement it (that's rules/) │\n│ • WHAT to do with it (that's todo/) │\n└─────────────────────────────────────────────────────────────────┘\n\nWhen to Use This Skill\n\nUse ogt-docs-define when you need to:\n\nUnderstand the definitions folder structure\nChoose the right definition sub-skill\nCreate a definition that doesn't fit specialized categories\n\nFor specific definition types, use:\n\nType\tSub-Skill\tUse When\nBusiness concepts\togt-docs-define-business\tPricing, users, revenue, market\nProduct features\togt-docs-define-feature\tNew capabilities, user-facing features\nTechnical architecture\togt-docs-define-code\tServices, data models, APIs\nMarketing concepts\togt-docs-define-marketing\tMessaging, positioning, audience\nBrand identity\togt-docs-define-branding\tVisual identity, tone, guidelines\nDeveloper tools\togt-docs-define-tools\tCLI, scripts, dev workflows\nFolder Structure\ndocs/definitions/\n├── business/ # Business model and operations\n│ ├── pricing_model/\n│ │ ├── definition.md\n│ │ ├── tiers.md\n│ │ ├── limits.md\n│ │ └── .approved_by_founder\n│ ├── user_types/\n│ ├── revenue_model/\n│ └── market_position/\n│\n├── features/ # Product features\n│ ├── global_search/\n│ │ ├── feature.md\n│ │ ├── mvp.md\n│ │ ├── phase_0.md\n│ │ ├── phase_1.md\n│ │ ├── nice_to_have.md\n│ │ └── .version\n│ ├── user_auth/\n│ └── campaign_manager/\n│\n├── technical/ # Architecture and systems\n│ ├── service_layer/\n│ │ ├── definition.md\n│ │ ├── contracts.md\n│ │ ├── patterns.md\n│ │ └── .version\n│ ├── data_model/\n│ └── api_design/\n│\n├── domain/ # Domain-specific concepts\n│ ├── creatures/\n│ ├── abilities/\n│ └── campaigns/\n│\n├── marketing/ # Marketing and communications\n│ ├── value_proposition/\n│ ├── target_audience/\n│ └── messaging/\n│\n├── branding/ # Brand identity\n│ ├── visual_identity/\n│ ├── tone_of_voice/\n│ └── brand_guidelines/\n│\n└── tools/ # Developer tooling\n ├── cli/\n ├── scripts/\n └── workflows/\n\nThe Folder-as-Entity Pattern\n\nEvery definition is a folder containing:\n\n{definition_slug}/\n├── {type}.md # Primary definition file\n├── {aspect}.md # Additional aspects/details\n├── {related}.md # Related concepts\n└── .{signals} # Status and metadata\n\nPrimary File Naming\nDefinition Type\tPrimary File\nBusiness\tdefinition.md\nFeature\tfeature.md\nTechnical\tdefinition.md\nDomain\tdefinition.md\nMarketing\tdefinition.md\nBranding\tdefinition.md\nTools\tdefinition.md\nDefinition Lifecycle\nflowchart LR\n subgraph lifecycle [\"Definition Lifecycle\"]\n D[draft] --> R[review]\n R --> A[approved]\n R --> REJ[rejected]\n REJ --> D\n A --> DEP[deprecated]\n end\n\n style D fill:#fef3c7\n style R fill:#e0e7ff\n style A fill:#d1fae5\n style REJ fill:#fecaca\n style DEP fill:#e5e7eb\n\nDraft State\n\nDefinition is being written, not yet ready for review.\n\n{definition_slug}/\n├── definition.md\n├── .version\n└── .draft # Empty signal: still in draft\n\nReview State\n\nDefinition is complete and awaiting approval.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .ready_for_review # Empty signal\n└── .review_requested_at # Timestamp\n\nApproved State\n\nDefinition is approved and can be referenced/implemented.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .approved # Empty signal\n├── .approved_by_{name} # Who approved\n└── .approved_at # When approved\n\nRejected State\n\nDefinition was rejected, needs rework.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .rejected # Empty signal\n├── .rejected_reason # Why rejected\n└── .rejected_at # When rejected\n\nDeprecated State\n\nDefinition is outdated, replaced by something else.\n\n{definition_slug}/\n├── definition.md\n├── .version\n├── .deprecated # Empty signal\n├── .deprecated_reason # Why deprecated\n├── .deprecated_at # When deprecated\n└── .superseded_by # What replaces it\n\nCreating a Definition: The Process\nflowchart TD\n A[Need to define something] --> B{What type?}\n B -->|Business| C[ogt-docs-define-business]\n B -->|Feature| D[ogt-docs-define-feature]\n B -->|Technical| E[ogt-docs-define-code]\n B -->|Marketing| F[ogt-docs-define-marketing]\n B -->|Brand| G[ogt-docs-define-branding]\n B -->|Tools| H[ogt-docs-define-tools]\n B -->|Other| I[Use this skill]\n\n I --> J[Ask clarifying questions]\n J --> K[Draft definition]\n K --> L[Request review]\n L --> M{Approved?}\n M -->|Yes| N[Mark approved]\n M -->|No| O[Address feedback]\n O --> K\n\nStep 1: Ask Clarifying Questions\n\nBefore writing any definition, gather information:\n\nCore Questions (always ask):\n\nWhat is the name/identifier for this concept?\nIn one sentence, what IS it?\nWhy does it need to exist? What problem does it solve?\nWhat is it NOT? (boundaries)\nWhat other concepts does it relate to?\n\nContext Questions (ask as relevant): 6. Who are the stakeholders? 7. Are there existing similar concepts? 8. What decisions led to this concept? 9. What are the success criteria?\n\nStep 2: Draft the Definition\n\nUse the appropriate template based on type (see sub-skills).\n\nGeneric Definition Template:\n\n# Definition: {Name}\n\n## Overview\n\nOne paragraph explaining what this is and why it exists.\n\n## Core Concept\n\nDetailed explanation of the concept.\n\n### Key Characteristics\n\n- Characteristic 1\n- Characteristic 2\n- Characteristic 3\n\n### Boundaries\n\nWhat this is NOT:\n\n- Not X\n- Not Y\n- Not Z\n\n## Relationships\n\nHow this relates to other concepts.\n\n| Related Concept | Relationship |\n| --------------- | -------------------------- |\n| Concept A | Uses/Contains/Depends on |\n| Concept B | Parallel to/Alternative to |\n\n## Examples\n\nConcrete examples that illustrate the concept.\n\n### Example 1: {Name}\n\nDescription of example.\n\n### Example 2: {Name}\n\nDescription of example.\n\n## Open Questions\n\nUnresolved questions that need future discussion.\n\n- Question 1?\n- Question 2?\n\nStep 3: Add Signal Files\n# Create version file\necho '{\"schema\": \"1.0\", \"created\": \"'$(date -Iseconds)'\"}' > .version\n\n# Mark as draft\ntouch .draft\n\nStep 4: Request Review\n# Remove draft signal\nrm .draft\n\n# Add review signals\ntouch .ready_for_review\necho \"$(date -Iseconds)\" > .review_requested_at\n\nStep 5: Handle Review Outcome\n\nIf Approved:\n\nrm .ready_for_review .review_requested_at\ntouch .approved\ntouch .approved_by_{reviewer_name}\necho \"$(date -Iseconds)\" > .approved_at\n\n\nIf Rejected:\n\nrm .ready_for_review .review_requested_at\ntouch .rejected\necho \"Reason for rejection\" > .rejected_reason\necho \"$(date -Iseconds)\" > .rejected_at\n# Then address feedback and restart from Step 2\n\nSignal Files Reference\nStatus Signals (empty files)\nSignal\tMeaning\n.draft\tStill being written\n.ready_for_review\tReady for review\n.approved\tApproved for use\n.rejected\tRejected, needs rework\n.deprecated\tNo longer current\nAttribution Signals (empty files)\nSignal\tMeaning\n.approved_by_{name}\tWho approved\n.created_by_{name}\tWho created\n.reviewed_by_{name}\tWho reviewed\nContent Signals (contain text)\nSignal\tContent\n.version\tJSON: {\"schema\": \"1.0\", \"created\": \"...\"}\n.rejected_reason\tWhy rejected\n.deprecated_reason\tWhy deprecated\n.superseded_by\tPath to replacement definition\n.review_requested_at\tISO timestamp\n.approved_at\tISO timestamp\n.rejected_at\tISO timestamp\n.deprecated_at\tISO timestamp\nReferencing Definitions\n\nWhen other documents reference a definition:\n\nSee [Definition: User Types](docs/definitions/business/user_types/)\nPer the [Service Layer Definition](docs/definitions/technical/service_layer/)\n\n\nWhen code implements a definition, add a comment:\n\n/**\n * Implements: docs/definitions/technical/service_layer/\n * @see definition.md for contracts\n */\nexport class UserService implements IService {\n // ...\n}\n\nCommon Mistakes\nMistake\tWhy It's Wrong\tCorrect Approach\nMixing definition with rules\tConflates WHAT with HOW\tKeep definition pure, put HOW in rules/\nNo boundaries section\tUnclear scope leads to scope creep\tAlways define what it is NOT\nSkipping review\tUnvalidated definitions cause misalignment\tAlways get approval\nEditing approved definitions\tBreaks references\tCreate new version or deprecate\nNo relationships section\tIsolated definitions miss connections\tMap relationships explicitly\nToo abstract\tCan't be implemented\tInclude concrete examples\nToo specific\tCan't adapt to change\tKeep at concept level\nQuality Checklist\n\nBefore requesting review, verify:\n\n Overview explains WHAT and WHY in one paragraph\n Core concept is detailed enough to understand\n Boundaries clearly state what this is NOT\n Relationships map to other definitions\n At least 2 concrete examples provided\n Open questions listed (if any)\n .version file created\n .draft signal present (will be removed when requesting review)" }, "trust": { "sourceLabel": "tencent", "provenanceUrl": "https://clawhub.ai/EduardoU24/ogt-docs-define", "publisherUrl": "https://clawhub.ai/EduardoU24/ogt-docs-define", "owner": "EduardoU24", "version": "1.0.0", "license": null, "verificationStatus": "Indexed source record" }, "links": { "detailUrl": "https://openagent3.xyz/skills/ogt-docs-define", "downloadUrl": "https://openagent3.xyz/downloads/ogt-docs-define", "agentUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent", "manifestUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent.json", "briefUrl": "https://openagent3.xyz/skills/ogt-docs-define/agent.md" } }