Skill: troioi-vn/meo-mai-moi (version 0.1.2)

--- name: meo-mai-moi description: "Use for Meo Mai Moi pet-owner tasks when an agent needs to help a user manage their pets through the documented API: listing pets, updating pet profiles, adding weights, vaccinations, medical records, or microchips, understanding helper profiles, or navigating placement workflows. Also use when the user asks how to authenticate to Meo Mai Moi, how to install or configure this skill, which prompts to give their agent, or how to safely automate day-to-day pet-management actions without guessing undocumented routes." --- # Meo Mai Moi Use this skill for user-facing pet-management help on Meo Mai Moi. Prefer documented `/api/*` endpoints and avoid inventing routes or payload fields. ## Required user setup Meo Mai Moi is hosted at https://meo-mai-moi.com. Before an agent can use Meo Mai Moi for a user, the user must manually sign in or register there, then create a personal API key/token at https://meo-mai-moi.com/developer. The user should provide that key to their agent securely, ideally as a local secret or environment variable, not by pasting it into public chats, shared prompts, GitHub issues, logs, or commits. Without this API key, the agent cannot access the user's pets or account data through the API. Useful official links: - App: https://meo-mai-moi.com - API token page: https://meo-mai-moi.com/developer - Docs: https://meo-mai-moi.com/docs - API integration guide: https://meo-mai-moi.com/docs/api-integration.html - Project page: https://project.meo-mai-moi.com ## Load the right reference Read only the reference file you need: - Read `references/api.md` for authentication, response format, documented endpoints, and API usage rules. - Read `references/domain-model.md` for pet, helper, relationship, and placement concepts. - Read `references/workflows.md` for task playbooks and safe execution patterns. - Read `references/examples.md` when the user asks how to install the skill, configure token loading, or phrase requests to their agent. ## Working rules - Prefer read operations first to discover current state before proposing or making updates. - Treat personal access tokens as bearer secrets. Load them from a local env file; never paste them into chat, commits, logs, or generated docs. - Assume the stable external contract is the documented pet-management slice unless the user explicitly says to work with another route and you can verify it. - Send `Accept: application/json` and `Authorization: Bearer <token>` for PAT-backed requests. - Expect the standard API envelope. Success is usually `{ success: true, data, message? }`. Errors are usually `{ success: false, data: null, message, error?, errors? }`. - Respect documented abilities: `read`, `create`, `update`, `delete`. - Do not assume PATCH support for pets. Use the documented methods. - For destructive changes like delete, ownership transfer, or status changes with real-world consequences, confirm intent unless the user clearly asked for that exact action. - When the task needs domain nuance, read the domain reference before acting. The app has relationship-based access and placement-specific lifecycle rules that are easy to mangle if you wing it. ## Output expectations When helping with Meo Mai Moi tasks: - Be explicit about which endpoint and method you are using. - Surface important constraints before risky writes. - If the contract looks incomplete for the requested task, say so plainly and stop guessing. - Prefer compact examples over long tutorials. - Default to the pet owner's perspective unless the user clearly asks for developer or backend-contract analysis.

path: references/api.md
content: # Meo Mai Moi API Reference

## Authentication

Use Sanctum personal access tokens for programmatic access.

To start using Meo Mai Moi through an agent, the user must manually sign in or register at https://meo-mai-moi.com, create a personal API key/token at https://meo-mai-moi.com/developer, and provide it to the agent securely, preferably through a local env file or secret manager. Do not ask users to paste API keys into public chats, shared prompts, GitHub issues, logs, or committed files.

Official docs:

- User/developer docs: https://meo-mai-moi.com/docs
- API integration guide: https://meo-mai-moi.com/docs/api-integration.html
- Project page: https://project.meo-mai-moi.com

Required headers:

- `Authorization: Bearer <token>`
- `Accept: application/json`

Practical env pattern:

```bash
set -a
source /path/to/meo-mai-moi.env
set +a
```

Example env file:

```env
API_KEY=...
```

Minimal identity/auth check:

```bash
curl -sS \
  -H "Authorization: Bearer $API_KEY" \
  -H "Accept: application/json" \
  https://meo-mai-moi.com/api/users/me
```

## Stable contract assumptions

Treat `/api/*` as the active v1 contract.

Documented pet-management contract:

- `GET /api/my-pets`
- `GET /api/my-pets/sections`
- `POST /api/pets`
- `GET /api/pets/{pet}`
- `PUT /api/pets/{pet}`
- `PUT /api/pets/{pet}/status`
- `DELETE /api/pets/{pet}`
- `POST /api/pets/{pet}/weights`
- `PUT /api/pets/{pet}/weights/{weight}`
- `DELETE /api/pets/{pet}/weights/{weight}`
- `POST /api/pets/{pet}/medical-records`
- `PUT /api/pets/{pet}/medical-records/{record}`
- `DELETE /api/pets/{pet}/medical-records/{record}`
- `POST /api/pets/{pet}/vaccinations`
- `PUT /api/pets/{pet}/vaccinations/{record}`
- `POST /api/pets/{pet}/vaccinations/{record}/renew`
- `DELETE /api/pets/{pet}/vaccinations/{record}`
- `POST /api/pets/{pet}/microchips`
- `PUT /api/pets/{pet}/microchips/{microchip}`
- `DELETE /api/pets/{pet}/microchips/{microchip}`

Do not assume `PATCH /api/pets/{pet}` is supported.

## Abilities

Current PAT ability enforcement:

- `read` for `GET /api/users/me`, `GET /api/my-pets`, `GET /api/my-pets/sections`
- `create` for pet creation and nested record creation
- `update` for pet updates, status updates, and nested record updates
- `delete` for pet deletion and nested record deletion

Session-authenticated browser requests are broader than PAT-backed requests. Do not assume a browser capability is a stable PAT contract.

## Response conventions

Success usually looks like:

```json
{
  "success": true,
  "data": {},
  "message": "Optional human message"
}
```

Error usually looks like:

```json
{
  "success": false,
  "data": null,
  "message": "Human-readable summary",
  "error": "Optional machine-ish code",
  "errors": {
    "field": ["Validation message"]
  }
}
```

Exception:

- `204 No Content` intentionally has an empty body.

## Useful known details

- `POST /api/pets` requires `country` as ISO 3166-1 alpha-2, for example `VN`.
- `GET /api/my-pets` and `GET /api/my-pets/sections` include compact `health_summary` data for list views.
- Some pet-health read endpoints are public or optional-auth. That does not make write operations public.

## Rate limits and quotas

Expect both minute throttles and a daily quota.

- Authenticated API group: production default is `60/min`
- Public API group: production default is `30/min`
- Regular users: `1000 requests/day` by default
- Premium users: unlimited
- Daily quota window resets at UTC day boundary

Over-quota responses use `429` and the error code `API_DAILY_QUOTA_EXCEEDED`.

## Safe usage pattern

1. Read first.
2. Confirm identifiers and current state.
3. Write the smallest change needed.
4. Re-read to verify the result.
5. If a route or payload is undocumented, say it is undocumented before using it.

## Handy examples

List my pets:

```bash
curl -sS \
  -H "Authorization: Bearer $API_KEY" \
  -H "Accept: application/json" \
  https://meo-mai-moi.com/api/my-pets
```

Get one pet:

```bash
curl -sS \
  -H "Authorization: Bearer $API_KEY" \
  -H "Accept: application/json" \
  https://meo-mai-moi.com/api/pets/123
```

Create a weight record:

```bash
curl -sS -X POST \
  -H "Authorization: Bearer $API_KEY" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -d '{"weight_kg":4.2,"record_date":"2026-04-26"}' \
  https://meo-mai-moi.com/api/pets/123/weights
```

The live API currently validates `weight_kg` and `record_date` for weight writes. Do not send `weight` or `recorded_at` unless the server contract changes and you re-verify it.


path: references/domain-model.md
content: # Meo Mai Moi Domain Model

## Pets

Pet profiles can include:

- basic info: name, age, sex, species
- location: country, state, city
- description and photos
- categories/tags
- health records: weights, vaccinations, medical records, microchips
- placement requests for rehoming, fostering, or sitting

## Pet relationships and access

A pet can have multiple active relationships with users.

Key relationship types:

- `owner`: full access, can transfer ownership and manage relationships
- `foster`: edit access for temporary care
- `editor`: edit access without ownership rights
- `viewer`: read-only access
- `sitter`: appears in placement lifecycle for pet-sitting flows

Important access model:

- Full profile access is relationship-based.
- Public profile access is narrower and field-whitelisted.
- Ownership and placement actions can have real-world consequences. Treat them carefully.

## Helper profiles

Helper profiles represent people who can respond to placement requests.

Important fields include:

- country, state, city
- address and zip code
- phone number
- contact details
- experience
- whether the helper has pets or children
- `request_types`: one or more of `foster_paid`, `foster_free`, `permanent`, `pet_sitting`
- `status`: private by default, `public` to appear in public listings

Visibility notes:

- Owners can always view their own helper profiles.
- Pet owners can view a helper profile when that helper responded to their placement request.
- Public helper pages hide phone numbers and structured contact details.
- Public helper visibility is stricter than merely existing; do not assume every helper profile is public.

## Placement concepts

Core models:

- `PlacementRequest`: owner’s request and overall state
- `PlacementRequestResponse`: helper’s response
- `TransferRequest`: physical handover confirmation object for flows that need one
- `PetRelationship`: source of truth for ownership and care access over time

Placement request types:

- `permanent`
- `foster_free`
- `foster_paid`
- `pet_sitting`

Placement request statuses used by current flow:

- `open`
- `pending_transfer`
- `active`
- `finalized`

Other enum values may exist, but do not assume they are part of the active public workflow.

## Practical agent guidance

- Before writing anything, understand whether the task touches pet data, helper data, relationship data, or placement state.
- If a task mentions adoption, fostering, handover, or return, read `workflows.md` before acting.
- If a task only needs straightforward pet CRUD or health records, the API reference may be enough.


path: references/examples.md
content: # Install and Example Prompts

## Install in OpenClaw

Put the skill folder in one of these locations:

- `<workspace>/skills/meo-mai-moi/`
- `<workspace>/.agents/skills/meo-mai-moi/`
- `~/.openclaw/skills/meo-mai-moi/`

Minimal layout:

```text
meo-mai-moi/
├── SKILL.md
└── references/
    ├── api.md
    ├── domain-model.md
    ├── examples.md
    └── workflows.md
```

After installing, start a new session or restart the gateway so OpenClaw reloads skills.

Useful checks:

```bash
openclaw skills list
openclaw agent --message "List my Meo Mai Moi pets"
```

## Connect your agent with an API key

Meo Mai Moi is hosted at https://meo-mai-moi.com.

To use Meo Mai Moi through an agent:

1. Sign in or register manually at https://meo-mai-moi.com.
2. Create a personal API key/token at https://meo-mai-moi.com/developer.
3. Provide that key to your agent securely.

Recommended setup: store the Meo Mai Moi API key in a local env file outside git.

Example:

```env
[REDACTED_SECRET]
```

The agent should load it from a local env file or secret manager and never commit it, log it, paste it into public chats, or echo it back unless the user explicitly asks to reveal it.

Without this key, the agent can understand the skill documentation but cannot access the user's Meo Mai Moi pets or account data.

Useful links:

- App: https://meo-mai-moi.com
- API token page: https://meo-mai-moi.com/developer
- Docs: https://meo-mai-moi.com/docs
- API integration guide: https://meo-mai-moi.com/docs/api-integration.html
- Project page: https://project.meo-mai-moi.com

## Example user prompts

These are good natural-language triggers for the skill:

- "List my pets from Meo Mai Moi."
- "Show me the current profile for Miu on Meo Mai Moi."
- "Add a new weight entry for Bánh Bao: 4.3kg today." (Agent should call the live API with `weight_kg` and `record_date`.)
- "Update this pet's description but keep everything else unchanged."
- "Check whether my Meo Mai Moi API key still works."
- "Explain what helper profiles are on Meo Mai Moi."
- "Help me understand whether this placement request is active or pending transfer."
- "Use Meo Mai Moi to add a vaccination record for my cat."

## Example agent behavior

Good behavior:

- Read current state first.
- Use documented routes.
- Match payload field names to the verified live contract, especially for nested health records.
- Confirm destructive actions.
- Re-read after writes.
- Explain state transitions for placement tasks.

Bad behavior:

- Invent undocumented endpoints.
- Use `PATCH` for pet updates without proof.
- Delete or transfer ownership casually.
- Expose PAT secrets in logs, chat, or commits.

## Suggested one-line setup note for users

"Use the Meo Mai Moi skill whenever I ask you to manage my pets, health records, helper profiles, or placement workflows through the documented API. Load my local API token from env, use read-first workflows, and avoid undocumented routes."


path: references/workflows.md
content: # Meo Mai Moi Workflows

## Read-only inspection workflow

Use for questions like:

- "List my pets"
- "Show this pet's current data"
- "Check whether this token works"

Steps:

1. Verify auth with `GET /api/users/me` if needed.
2. Read the smallest endpoint that answers the question.
3. Summarize the result using the response envelope's `data` field.
4. Avoid extra follow-up calls unless they materially improve the answer.

## Pet update workflow

Use for creating or updating pet data, status, or nested health records.

1. Read the current pet or pet list first.
2. Confirm the target pet identifier.
3. Use the documented `PUT` or `POST` route.
4. Re-read the resource after the write.
5. Tell the user exactly what changed.

Guardrails:

- Do not switch to undocumented `PATCH` calls.
- For deletes, ownership changes, or status changes that could affect visibility or operations, confirm first unless the user already clearly instructed it.

## Health record workflow

Use for weights, medical records, vaccinations, and microchips.

1. Inspect current pet data or the relevant nested list if needed.
2. Create or update only the relevant nested record.
3. If the action affects history, preserve chronology and avoid overwriting the wrong entry.
4. Verify by re-reading the record or parent pet.

## Placement workflow

Use extra care. This domain has lifecycle state and relationship consequences.

### Placement summary

- Owner creates a placement request.
- Helpers respond.
- Owner accepts a response.
- `pet_sitting` becomes `active` immediately and creates or ensures a sitter relationship.
- `permanent` and `foster_*` go to `pending_transfer` and create a `TransferRequest`.
- Helper confirms physical handover.
- `permanent` transfers ownership and finalizes the request.
- `foster_*` starts foster access and marks the request active.
- Owner later finalizes temporary placements when the pet is returned.

### Agent rules for placement tasks

- Read current placement state before proposing the next action.
- Never improvise lifecycle transitions.
- Call out whether the flow is `pet_sitting`, `permanent`, or `foster_*`; they differ materially.
- If the user asks for an action that implies handover, acceptance, rejection, or finalization, explain the current state and the next documented step.
- Prefer owner-scoped actions for normal app use; admin behavior is a separate concern.

## Helper profile workflow

Use for creating, updating, or inspecting helper profiles.

1. Read visible helper profiles or the specific target profile first.
2. Confirm visibility expectations: private vs public.
3. Update only the intended profile fields.
4. Re-read after writing.

Guardrails:

- Do not leak phone numbers or structured contact details from contexts that should be public-only.
- Do not assume every helper profile can be fetched through public endpoints.

## When the contract is incomplete

If the user asks for notifications, messaging, profile-adjacent features, or other areas not clearly described as stable PAT-backed contract:

1. Say the public contract appears incomplete for that area.
2. Use only documented routes unless the user explicitly wants exploratory work.
3. If exploring, label assumptions and verify each step.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)