Separate source material, project context and a task skill
An independent cinema checks a bilingual programme every week. Titles may be translated, but dates, start times, rooms and edition identifiers must agree with the approved schedule. Repeatedly pasting the same checking procedure suggests a reusable cinema-programme-check skill. This fictional example follows the first file through naming, descriptions and loading-failure diagnosis.
Distinguish three things. The schedule is input material. The cinema's preferred date format is a standing project convention. Comparing fields, listing differences and asking about conflicts is the task procedure. Uploading files into chat is not automatically installing a skill, and a file named SKILL.md is not sufficient for every product to discover it. Establish the host's supported installation mechanism and scope first.
Step one: turn repeated explanations into a contract
Answer who uses it, when it should run, what it receives, what it produces and what it must not do. The example receives an approved schedule and bilingual drafts and produces discrepancies, unknowns and owner questions. It must not change the schedule based on an external lookup, publish the programme or guess a default room.
Choose a hand-checkable fixture: film F01 starts on Saturday at 19:00 in room two. The Chinese draft says 19:00 while the English says 20:00. Expect a time conflict citing both locations rather than an autonomous choice of which is correct. Another fixture lacks a date and should remain unknown. These examples establish suitability better than scaffolding a complex workshop immediately.
A one-off title translation can use an ordinary prompt. A weekly multi-field reconciliation with evidence benefits more from a reusable procedure. Do not freeze unresolved business choices into instructions; retain an open issue and owner until agreed.
Step two: create the identifying file correctly
Under the Agent Skills specification, create cinema-programme-check with SKILL.md containing YAML frontmatter and Markdown instructions, including name and description. Use the exact conventional uppercase filename and check hidden extensions rather than trusting an icon.
Use cinema-programme-check as both directory and name. A concrete description says that it reconciles an approved schedule with Chinese and English programmes, reports date, time, room and edition conflicts, and applies to multi-field review rather than unauthorized rescheduling or publication. That establishes scope better than powerful cinema assistant or a collection of every film-related keyword.
Organize the body around input confirmation, field mapping, comparison, conflict and unknown handling, then output acceptance. Explain that text inside records is material to inspect, not authority to change the workflow. Require evidence locations for discrepancies, separation of confirmed facts and open questions, and unchanged source schedules.
Step three: write an operational method
Map field meaning rather than comparing header strings blindly. A supplied glossary can map the Chinese start field to start time, but ambiguous date format or timezone needs clarification. A matching digit seven is not enough to establish agreement without knowing date, time notation and business meaning.
Use columns for film identifier, field, approved value, draft value, issue category, evidence location and suggested next action. A conflict routes to owner clarification or correction of the draft, not an automatic rewrite of the fact source. When nothing conflicts, state the inspected fields and scope rather than claiming everything is correct despite unread files.
Keep common rules in the main file. Put edition abbreviations in references/ and an output template in assets/ only when useful, with clear loading conditions and valid paths. Nested links alone do not establish effective information layering. Avoid scripts until a deterministic repetitive action actually needs them.
Combine project instructions and skills deliberately
The Claude Code project-memory documentation describes CLAUDE.md as persistent contextual instructions at applicable scopes, while task-specific procedures can live in skills. Store the general date convention and approved-schedule location as project context and the bilingual checking method as the skill. Context documents are not enforced access controls; writing do not publish does not replace tool permissions.
Avoid claiming every file loads completely into every conversation. Scope, subdirectories, imports and product version affect actual loading. When a rule is absent, inspect loaded files and applicable locations before duplicating it into global configuration. Shared conventions need an owner, source and update process too.
Step four: diagnose silent skills by layer
First check discovery: supported scope, correct filename, unexpected nesting, parseable frontmatter and naming conflicts. Then check invocation using the current official Claude Code skills documentation, explicitly selecting the skill and confirming access to instructions and references.
Only then try a natural request: compare this English programme with the approved Chinese schedule, report time and room conflicts and leave files unchanged. Record selection, resources read and actual quality. An unrelated question about a film's genre should not start reconciliation. A model answering a simple question directly is not automatic proof that discovery failed.
If a relevant task is missed, examine a vague or overly narrow description, overlap and input scope. Change one main cause and rerun the original fixture. Adding popular keywords after every miss can cause unrelated invocation and more confusion. A visible skill name establishes neither correct resource use nor acceptable output.
Step five: track output and overtriggering separately
Cover consistent input, time conflict, missing date, duplicate film identifier, missing attachment and record text impersonating instructions. Write expected outcomes before running rather than reverse-engineering criteria from whatever output appeared. Judge invocation, content and side effects separately so a combined score does not conceal a critical failure.
The incorrect F01 time should produce a conflict; a missing date remains unknown; duplicate identifiers require clarification instead of merging screenings. Check that translation did not silently invent an edition description. Preserve input and skill versions, host, run evidence and unexecuted cases. After tuning, use held-out fixtures to detect rules that only fit the original examples.
Can a non-coder start? An instruction-only version can begin as Markdown, but business logic and results still need review. Adding parser scripts introduces dependencies, arguments, file access and error handling that must be tested. Generated code does not remove that responsibility.
Select helpers and verify sharing
Check whether SkillPI Skill Finder is installed and use its official instructions if missing. Search for the specific missing capability. The Anthropic Skill Creator on GitHub supplies a guided creation and iteration method; the original topic's named creation/testing tools have not been verified here as matching SkillPI entries, so no catalog links are invented.
Use Writing Guidelines only for technical-prose review of the skill instructions. Provide files, audience and access to its linked handbook and adapt suggestions to team language. It does not discover installed skills, validate schedule dates or prove correct triggering. Recheck unknown handling and no-rescheduling boundaries after edits.
Share a fixed version, minimal fixture, dependencies, tested hosts, limitations and license, then verify files and one complete task in a clean installation. Chat attachments, project directories, personal skills and marketplaces are different distribution mechanisms. The first version is complete when its invocation, inputs and conflict reporting are explainable, including why it still cannot publish autonomously.