← Plugin catalog
Education & Research

Nihontekini

Nihontekini v1.0.0

Study Japanese with your decks

Create a free account to save this plugin.

From the developer

Declared limitations

  • Unrelated request should not use the plugin
  • Bulk delete must ask for confirmation first
  • No access to other people's data

Not specified in the available declarations: capabilities, pricing & account requirements.

Onboarding example

Add 20 N5 food words to a Kitchen deck.
Sources & dates

Developer declarations; not independently tested. Listing last checked Nov 6, 2026. Package observed Nov 5, 2026.

View package source →

Description

From the marketplace listing

Create and manage Japanese vocabulary flashcards in Nihontekini from ChatGPT. Build decks from a topic, JLPT level or text, look up and explain words, fix or suspend cards, check your learning progress and practice the words you keep forgetting with personalized quizzes. Cards include readings, English meanings, explanations and example sentences, and sync to the Nihontekini iOS app. Connect your Nihontekini account to start.

Language: English · Automatically detected from descriptions.

Changes

No changes recorded yet. Follow this plugin to keep track of future changes.

First seen Nov 5, 2026. Last seen Nov 6, 2026.

Keywords

Files & skills

File archives

Plugin package17 files · 205 KBBrowse files →
Skill instructions
build-deck2.81 KB

View saved version →

---
name: build-deck
description: Use when a user asks to build or extend Japanese vocabulary decks from a topic, JLPT level, pasted text, lyrics, menus, signs, or photos.
---

## Workflow
1. Identify the learner's topic/level and derive distinct, useful Japanese terms. For copyright-protected text, extract only vocabulary needed for study, not entire lyrics.
2. Call `list_decks`. Reuse a suitable user-owned deck or choose `deck_name` for a new deck. Never attempt to add to a predefined `own: false` deck.
3. If the user wants to avoid known vocabulary, call `get_learned_words` and filter the returned terms.
4. Put the most practical words first. A refused add_cards call adds nothing; if the refusal says only some cards can be added, retry once with at most that many of the most practical words and clearly disclose the number omitted. Terms already in the deck may be skipped but don't assume that will free room.
5. Prepare 1–2 natural examples and an informative concise nuance for each word. For standard dictionary words omit `reading`/`meaning` when appropriate so JMdict can populate them; for slang and fixed expressions provide clean English glosses and kana.
6. Call `add_cards` in chunks of no more than 200. If it refuses, handle it as in step 4.
7. Report new, duplicate/skipped and omitted counts based on real tool results, not intent. State where the deck appears on sync.

## Cross-workflow rules
- Use only Nihontekini MCP tools with exact server-returned IDs; never invent card, deck, quiz, or user IDs. Authentication failures: ask the user to reconnect the plugin.
- Card `meaning` must contain only plain English glosses (e.g. `["to study", "diligence"]`). Put kana in `reading`, usage and grammar in `explanation`, and never include romaji, pronunciation, kana, part of speech, or annotations inside `meaning`. The `reading` field contains kana, never romaji.
- Examples should be natural, with Japanese text in `jp` and, when available, Anki-style furigana in example `reading`, e.g. `日本語[にほんご]を 勉強[べんきょう]しています。`.
- In chat, when showing Japanese, give kana and romaji alongside kanji as appropriate; in a question that tests reading, never spoil the answer with reading or romaji.
- Never include raw JSON tool payloads or credentials in the conversation. Summarize results concisely in the user's language.
- Send at most 200 cards per add/suspend/delete request and 30 questions per quiz. On a 429 Too Many Requests, respect Retry-After and avoid hammering.
- If a tool refuses (`isError`), pass its message on plainly and stop without retrying unless the message says what to change. Never claim the assistant can buy or change anything on the account.
- Mention that newly created or edited cards appear on the phone after the next sync (pull to refresh). Never promise immediate propagation.

Referenced files: 1 — file references are metadata, not package contents.

explain-word2.33 KB

View saved version →

---
name: explain-word
description: Use when the user asks what a Japanese term, phrase, or kanji means and may want to save it as a Nihontekini card.
---

## Workflow
1. Call `search_dictionary` for kanji/kana/romaji or English keyword when a lookup is relevant; do not present guessed JMdict entries as confirmed results.
2. Explain meanings, reading, register, usage, common confusions and one natural example. Present Japanese with kana and romaji in chat. If ambiguous, explain possible senses and ask which one applies.
3. Optionally call `find_cards` to see whether the word is already in the user's decks. Never claim it is saved unless confirmed.
4. If user asks to add it, follow build-deck logic: list decks and add it with clean English glosses, not romaji in `meaning`.
5. If the dictionary doesn't find a term, say so and offer a tentative language explanation separately without inventing an entry.

## Cross-workflow rules
- Use only Nihontekini MCP tools with exact server-returned IDs; never invent card, deck, quiz, or user IDs. Authentication failures: ask the user to reconnect the plugin.
- Card `meaning` must contain only plain English glosses (e.g. `["to study", "diligence"]`). Put kana in `reading`, usage and grammar in `explanation`, and never include romaji, pronunciation, kana, part of speech, or annotations inside `meaning`. The `reading` field contains kana, never romaji.
- Examples should be natural, with Japanese text in `jp` and, when available, Anki-style furigana in example `reading`, e.g. `日本語[にほんご]を 勉強[べんきょう]しています。`.
- In chat, when showing Japanese, give kana and romaji alongside kanji as appropriate; in a question that tests reading, never spoil the answer with reading or romaji.
- Never include raw JSON tool payloads or credentials in the conversation. Summarize results concisely in the user's language.
- Send at most 200 cards per add/suspend/delete request and 30 questions per quiz. On a 429 Too Many Requests, respect Retry-After and avoid hammering.
- If a tool refuses (`isError`), pass its message on plainly and stop without retrying unless the message says what to change. Never claim the assistant can buy or change anything on the account.
- Mention that newly created or edited cards appear on the phone after the next sync (pull to refresh). Never promise immediate propagation.

Referenced files: 1 — file references are metadata, not package contents.

fix-cards2.57 KB

View saved version →

---
name: fix-cards
description: Use when the user wants to find, correct, move, suspend, unsuspend, or delete Japanese flashcards in Nihontekini.
---

## Workflow
1. Call `find_cards` with exact term or filter. If many matches, present enough context to disambiguate before changes.
2. For edits or moves, ensure `own` is true and call `edit_card` with only requested fields. Keep meaning English-gloss-only; explain nuance elsewhere. Existing scheduling progress is retained.
3. For "already know" or "skip" requests, prefer `suspend_cards` (or unsuspend when requested), which is supported for predefined as well as own cards. Max 200 IDs per call.
4. Never edit/delete predefined cards (`own: false`). Explain that they can only be suspended.
5. Before `delete_cards`, enumerate exact cards and confirm explicitly in the current conversation because deletion destroys progress; don't proceed based on a vague "clean up" request. Delete only confirmed owned IDs, max 200 per batch.
6. Report only confirmed tool changes and remind about the next iOS sync. Handle auth failure, duplicates or missing records by explaining what was found, not guessing IDs.

## Cross-workflow rules
- Use only Nihontekini MCP tools with exact server-returned IDs; never invent card, deck, quiz, or user IDs. Authentication failures: ask the user to reconnect the plugin.
- Card `meaning` must contain only plain English glosses (e.g. `["to study", "diligence"]`). Put kana in `reading`, usage and grammar in `explanation`, and never include romaji, pronunciation, kana, part of speech, or annotations inside `meaning`. The `reading` field contains kana, never romaji.
- Examples should be natural, with Japanese text in `jp` and, when available, Anki-style furigana in example `reading`, e.g. `日本語[にほんご]を 勉強[べんきょう]しています。`.
- In chat, when showing Japanese, give kana and romaji alongside kanji as appropriate; in a question that tests reading, never spoil the answer with reading or romaji.
- Never include raw JSON tool payloads or credentials in the conversation. Summarize results concisely in the user's language.
- Send at most 200 cards per add/suspend/delete request and 30 questions per quiz. On a 429 Too Many Requests, respect Retry-After and avoid hammering.
- If a tool refuses (`isError`), pass its message on plainly and stop without retrying unless the message says what to change. Never claim the assistant can buy or change anything on the account.
- Mention that newly created or edited cards appear on the phone after the next sync (pull to refresh). Never promise immediate propagation.

Referenced files: 1 — file references are metadata, not package contents.

progress-check2.08 KB

View saved version →

---
name: progress-check
description: Use when a user asks how their Japanese learning is going, what is due, how many words they know, or for a weekly progress report.
---

## Workflow
1. Call `get_progress` to obtain known/started words, due reviews and last-seven-day activity. Optionally call `get_weak_words` for concrete practice targets.
2. Give a compact summary: counts with explicit time window, one observable pattern, and one achievable next action. If results are empty, say the user has no tracked reviews yet and suggest beginning a deck.
3. Do not invent historical comparisons, streaks, study times or trends that the tools did not provide.

## Cross-workflow rules
- Use only Nihontekini MCP tools with exact server-returned IDs; never invent card, deck, quiz, or user IDs. Authentication failures: ask the user to reconnect the plugin.
- Card `meaning` must contain only plain English glosses (e.g. `["to study", "diligence"]`). Put kana in `reading`, usage and grammar in `explanation`, and never include romaji, pronunciation, kana, part of speech, or annotations inside `meaning`. The `reading` field contains kana, never romaji.
- Examples should be natural, with Japanese text in `jp` and, when available, Anki-style furigana in example `reading`, e.g. `日本語[にほんご]を 勉強[べんきょう]しています。`.
- In chat, when showing Japanese, give kana and romaji alongside kanji as appropriate; in a question that tests reading, never spoil the answer with reading or romaji.
- Never include raw JSON tool payloads or credentials in the conversation. Summarize results concisely in the user's language.
- Send at most 200 cards per add/suspend/delete request and 30 questions per quiz. On a 429 Too Many Requests, respect Retry-After and avoid hammering.
- If a tool refuses (`isError`), pass its message on plainly and stop without retrying unless the message says what to change. Never claim the assistant can buy or change anything on the account.
- Mention that newly created or edited cards appear on the phone after the next sync (pull to refresh). Never promise immediate propagation.

Referenced files: 1 — file references are metadata, not package contents.

quiz-me2.76 KB

View saved version →

---
name: quiz-me
description: Use when a user asks to quiz, test, drill, or practice weak Japanese words from their Nihontekini decks.
---

## Workflow
1. Choose recorded vs informal mode. Recorded mode uses `make_quiz` (max 30 questions), which consumes one AI-generated quiz and saves a quiz record; avoid making a quiz just to preview it. Informal mode calls `get_learned_words`/`get_weak_words` and is not recorded.
2. If a user wants the weakest vocabulary, use `get_weak_words` to choose the level. If recorded mode is requested, call `make_quiz` once; handle empty decks, auth errors and `isError` refusals without retrying. If it refuses, suggest informal practice from existing words or Test me in the app.
3. Ask one question at a time. Do not reveal correct option, kana, or romaji before the user answers if those are under test. Keep correct answers private while asking.
4. Give short feedback after each response; store the user's selection as the exact requested `picked` representation. Don't record questions they didn't answer.
5. For recorded quizzes, call `record_quiz_answers` once using the exact returned quiz_id and card_ids, up to 30 responses. If the session ends early, record only answered questions when appropriate.
6. Give the score and 3–5 words to revisit. If no practice data exists, explain what to review first.

## Cross-workflow rules
- Use only Nihontekini MCP tools with exact server-returned IDs; never invent card, deck, quiz, or user IDs. Authentication failures: ask the user to reconnect the plugin.
- Card `meaning` must contain only plain English glosses (e.g. `["to study", "diligence"]`). Put kana in `reading`, usage and grammar in `explanation`, and never include romaji, pronunciation, kana, part of speech, or annotations inside `meaning`. The `reading` field contains kana, never romaji.
- Examples should be natural, with Japanese text in `jp` and, when available, Anki-style furigana in example `reading`, e.g. `日本語[にほんご]を 勉強[べんきょう]しています。`.
- In chat, when showing Japanese, give kana and romaji alongside kanji as appropriate; in a question that tests reading, never spoil the answer with reading or romaji.
- Never include raw JSON tool payloads or credentials in the conversation. Summarize results concisely in the user's language.
- Send at most 200 cards per add/suspend/delete request and 30 questions per quiz. On a 429 Too Many Requests, respect Retry-After and avoid hammering.
- If a tool refuses (`isError`), pass its message on plainly and stop without retrying unless the message says what to change. Never claim the assistant can buy or change anything on the account.
- Mention that newly created or edited cards appear on the phone after the next sync (pull to refresh). Never promise immediate propagation.

Referenced files: 1 — file references are metadata, not package contents.

Release notes

Simpler skill instructions.

Declared in the saved package. Remote tools may change independently.

Package details

Publisher declarations from the archived package. These are separate from our research and the live service's terms.

Package author
Nihontekini
Keywords
See keywords
Review scenarios
5 positive · 3 negativeScenario counts, not test results.

Some manifest fields differ or could not be read. The structured report retains the source references.

Package observed Nov 5, 2026.

Technical details
First seen
Nov 5, 2026 · 12:00 UTC
Last seen
Nov 6, 2026 · 00:00 UTC
Collection status
Collected

plugin_asdk_app_6adddc8f05f0819182a3d415616d8e68

Download plugin data (JSON)