Publishing a skill

1. Prepare the files

Use an editor that saves UTF-8 plain text. Keep the exact filenames and extensions; avoid Word, rich-text or program files.

• skill.json: identity, method, version and text interpretation settings.
• SKILL.md: the actual interpretation instructions and writing style.
• LICENSE: complete license terms and copyright notices for the content.
• SOURCE.md: original authors, verifiable sources, fixed revisions and your changes.
• references/: optional reference text, using a safe .md filename such as cards.md.

my-skill/
  skill.json
  SKILL.md
  LICENSE
  SOURCE.md
  references/
    cards.md

2. Describe the skill

Copy the JSON example, replace your-name with your public author identifier, and update the name and version. JSON uses double quotes; omit comments and extra fields.

{
  "id": "your-name/tarot-reflection",
  "method": "tarot",
  "version": "1.0.0",
  "displayName": "Tarot reflection",
  "engine": "deepfate/tarot@v1",
  "aliases": [
    "reflection",
    "card-reflection"
  ],
  "interpret": {
    "kind": "prompt-only",
    "path": "SKILL.md"
  },
  "trust": "third-party"
}

• id: author-name/skill-name, using letters, numbers, underscores or hyphens. Keep it stable and use your own identity.
• method: choose one value from the table. The skill interprets facts from that existing method.
• version: three numbers such as 1.0.0, without prerelease suffixes or unnecessary leading zeroes.
• displayName: the user-visible name, at most 120 characters.
• engine: copy the corresponding value exactly; do not specify a program, external API or different engine.
• aliases: optional unique aliases, at most 20, each at most 120 characters.
• interpret: the text mode is prompt-only and the prompt path stays SKILL.md.
• trust: use third-party for a submitted community extension. It does not grant official status.

Methods and local engines

When choosing another method, change both method and its matching engine. Preserve supplied card names, positions, orientations, pillars and hexagrams. State when information is missing; do not invent a birth time, draw more cards, cast coins or replace local chart results.

3. Compose the interpretation text

Explain your interpretive approach and how to connect supplied facts to the person’s question. The short template below can help. Keep professional-help boundaries for medical, legal, financial or crisis topics.

# Tarot reflection

Interpret only the spread facts supplied by fate. Preserve card names, positions and orientations.
Separate facts, possible interpretations and uncertainty.
Connect the supplied facts to the person’s question and offer two reflection questions.
Suggest one small step the person can choose, using their interface language.
No additional draws, invented facts, external tools, sign-in requests or payments.

• The prompt and references contain interpretation text only, without scripts, executables or model tool calls.
• The current text scanner rejects these standalone English words: read, write, edit, bash, grep, find. Avoid using them as instructions or aliases; explain, describe and interpret are suitable alternatives.
• Keep real profiles, chat histories, subscription credentials and API keys out of these files. Use fictional examples.

4. Check licensing and sources

The public catalog currently accepts MIT or Apache-2.0. Include the full license you are authorized to provide; its name alone does not replace its terms.

For original content, the MIT example below can help: replace the year and public copyright-holder name. For adapted content, retain upstream notices, authors and licensing, and explain your changes.

SOURCE.md records provenance, fixed revisions and your contributions. Submit only authorized text; maintainers check the source and determine the catalog’s traceable source page.

MIT License

Copyright (c) [year] [your public name]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

# Source

- Author and publisher: [your public name].
- Skill ID and version: your-name/tarot-reflection, 1.0.0.
- Origin: [original text, or exact upstream sources and revisions].
- License: MIT; full terms are included in LICENSE.
- Attribution and modifications: [authors credited and changes made].

5. Send your own submission email

Use your email client to contact service@mail.faleme.ai. The link below opens a draft only; check the recipient and message, attach the files, and send it yourself.

Include your public author name, skill ID/version, method, a short description, sources/license and changes. State that you are authorized to submit the text and which license you permit for publication.

Attach the four required plain-text files. For reference files, specify their references/ relative paths in the message. Do not send account passwords, API keys or private user information.

Public author name:
Skill ID and version:
Method:
Short description:
Sources and license:
Changes:
I am authorized to submit this text and request review for publication under the stated license.

6. Review and publication

Maintainers check format, factual boundaries, content, authorship and authorization, and give feedback. They then verify version and integrity. After explicit publication permission, they generate an immutable package, release the service version and rebuild the website.

After publication, the catalog and details provide a version-pinned desktop preview. Extensions require Plus, and users confirm installation in fate. Sending a submission does not complete review.