A skill appearing in Cursor's list does not mean it has become part of daily work. The missing connection may be task relevance, stage inputs or acceptance evidence. This tutorial joins automatic invocation, subagent responsibilities and a repeatable development loop around a fictional community seed-exchange catalog. Visitors filter varieties, inspect availability states and read exchange guidance. It is a workflow design, not a claim that the example project or its agents have already been created and executed.
Separate methods, constraints and execution roles
A skill supplies a method for a type of task. Project rules supply constraints. A subagent takes responsibility for delegated work. They should not replace one another: making every procedure permanent increases conflicts, while splitting a simple review into several roles can add handoff effort without a useful independent output. Confirm that the project runs, relevant files are readable and existing changes are recorded. Establish a baseline with synthetic catalog records. State one objective: filtering must preserve the distinction between available, exhausted and unknown stock, and the guidance must remain readable. Exclude personal information, real exchange invitations and production changes. Every completed stage should identify files, evidence and unresolved questions. Use SkillPI Skill Finder to discover candidates, then inspect each source revision, licence, tool dependency and permission requirement. Three verified packages have defined roles here. Frontend Design shapes the catalog's visual direction and interface implementation. Webapp Testing verifies the local filter journey. Writing Guidelines reviews technical handoff notes. None is an automatic dispatcher or a subagent factory; orchestration remains a task-design and host-capability concern.
Scenario one: make invocation conditions testable
After installation, first make an explicit invocation and then observe task-based use. Do not assume installation guarantees that a procedure will be selected every time. The Cursor skills documentation describes contextual and manual invocation. Use the current interface and actual loading behaviour. A project usage register can explain the intended mapping, but the register itself is not an enforcement mechanism. Give the register columns for stage, task signal, target skill, input, output and exclusions. For interface work, the signal is implementing the catalog filter page; inputs include the page objective, design constraints and approved synthetic records; output is a code patch. For browser verification, the signal is checking post-filter states; input is a running address and expected behaviour; output is screenshots and findings. For document review, the input is the technical handoff and the output is location-based suggestions. Casual conversation or a plain record count does not need those methods. Test a positive example, a nearby negative and a clearly unrelated task. A positive asks for a filter control implementation. A nearby negative asks only to explain existing CSS without a redesign. An unrelated task counts varieties in supplied data. Record the observed invocation and output. If the wrong procedure intrudes, narrow the description or choose an explicit invocation method; do not widen it to every development task simply to improve activation frequency. Project rules can preserve existing edits, exclude generated files and require the repository's check commands. The Cursor rules documentation explains scope and application modes. A file-scoped rule is not the same object as skill metadata. Save previous configuration before changing it and avoid making every instruction always applicable. Contradictory permanent guidance is a maintenance problem, not stronger automation.
Scenario two: delegate only when a role has an independent output
A larger task may benefit from implementation, verification and review roles. Separate context does not guarantee freedom from file conflicts and is not a security sandbox. The Cursor subagent documentation describes configuration locations such as project-level .cursor/agents/ and the trade-offs involved. Check current fields, tool availability and actual skill loading rather than assuming a new role inherits another conversation's context or packages. Write a role contract for the catalog exercise. The implementer may edit the relevant page and styles, read the design brief and synthetic data, and deliver a patch plus startup instructions. The verifier begins after implementation stabilises, reads a frozen version and writes evidence without silently changing product logic. The documentation reviewer reads the handoff and returns suggestions. The main owner integrates findings and decides the next revision. Parallelise only work that does not compete to write the same files. For example, one role might research empty-state wording while another inspects existing test entry points. Changes to a shared component or configuration should be sequenced. Each role needs its objective, allowed scope, source version, inputs, exit conditions and report format. Missing prerequisites should produce a missing-input report, not a fictional completion claim. Frontend Design needs an audience, function, visual direction, editable code and a suitable runtime. It does not validate user research or certify accessibility compliance. Webapp Testing needs relevant Python and browser dependencies plus the local service; it does not establish safe concurrent stock allocation. Writing Guidelines needs the technical document and associated handbook rather than authority to invent facts. Delegating a skill does not remove its prerequisites or extend its purpose. A role result is useful only when another person can inspect it. Ask for concrete findings, changed paths, commands and limitations. If two reports disagree, return to the frozen inputs and the precise acceptance condition. Do not resolve a conflict merely by preferring the more confident summary.
Scenario three: use seven delivery checkpoints
The first checkpoint defines scope: filter variety and availability, preserve navigation and label unknown stock as awaiting confirmation. The second plans the state source, relevant pages, necessary checks and rollback. The third scaffolds the smallest structure within existing components and interfaces rather than rebuilding the entire site for a demonstration. The fourth implements the interface with Frontend Design. Establish a clear catalog hierarchy, status labels, filter controls and an empty state, then connect that design to project code. Do not distinguish available and exhausted records by colour alone; labels and control states should also communicate meaning. Product guidance must come from approved project content, not new rules invented during visual design. The fifth checkpoint verifies behaviour. Run the relevant project checks, then use Webapp Testing to inspect the page, operate the filter, check states and return to the initial view. Preserve synthetic inputs, reproduction steps and evidence. A browser failure should identify the expected and observed result, not merely say that the screen looks wrong. The sixth reviews and hands over the change. Inspect the complete diff against scope and findings. Use Writing Guidelines to review startup instructions, state definitions and unverified concerns. The seventh creates a commit or a ready-to-review delivery according to the user's authorisation. Without authorisation to commit, push or publish, retain the patch and explanation. These seven checkpoints are this article's operating design, not a claim that an installation package has automatically completed them. Give every checkpoint an exit condition. An unresolved state definition blocks design. A site that cannot start needs a prerequisite report. A failed check returns to the relevant change. A factual gap in the handoff returns to its owner. Knowing exactly where evidence is missing prevents the workflow from continuing into a larger pile of unreviewable files.
Walk through one filter request
Prepare three fictional records: S21 is available, S22 is exhausted and S23 has an unknown state. Selecting “available only” should show S21. Clearing the filter should restore all three. A nonexistent variety should produce an empty state with a route back. The guidance page uses text approved by the project owner; the design package does not invent new exchange eligibility or promises. Ask the implementer to explain how data reaches the list before making the bounded change. Freeze the implementation and startup steps when it is ready. The verifier then follows the stated expectations. If clearing the filter leaves only one record visible, report the locator, action sequence and observed state and return the issue to implementation. Do not quietly repair the logic inside the verification role and blur the tested version. The delivery bundle contains scope, patch, browser evidence, document suggestions and unverified boundaries. The article has not run this exercise; readers must retain their own results. Real invitations, authorisation and concurrent stock updates require separate verification. If there is no useful parallel work, a single agent can follow the same checkpoints serially. Additional roles are optional operational choices, not a requirement for using skills well. For a second iteration, change one requirement at a time. A new filter for seed type should reuse the state contract and extend the relevant cases. Recheck the existing clear-filter behaviour so a new control does not break a previously accepted path. Keep evidence associated with the version it actually examined rather than carrying a past passing label forward indefinitely.
Troubleshooting and frequently asked questions
Why did the skill not activate? Check discovery, task fit, explicit invocation and execution prerequisites before editing trigger wording. Why do rules conflict? List the contradictory instructions, file scopes and sources. Change one factor, preserve the previous version and repeat the relevant check. How should multi-file work be controlled? Bound the modules and interface contract, review in batches and avoid unrelated formatting while the feature is incomplete. Does adding subagents always make work faster? No. Startup, context gathering and integration consume time and usage; they must earn their place through an independent useful output. Can skills synchronise seamlessly across tools? Check directories, revisions, runtimes and available tools. Identical package text does not guarantee identical behaviour. Where does Finder belong? When a workflow stage lacks a method, discover a candidate and explain its intended role before inspecting and considering installation. A search result does not broaden the task's permissions. Maintain the usage register, retire candidates with no current purpose and inspect source changes before updates. Recheck a fixed sample after a package or host change. Removing a package does not undo files it already wrote, so rollback also requires reviewing project changes. Judge the workflow by clear acceptance, reproducible failures and manageable handoff effort rather than invocation counts or the number of installed names.