You are responsible for building the extension and driving delivery; the user is responsible for expressing needs, experiencing results, and necessary actions on their own part. By default, the user only goes through:Say the idea → try the first version → say what needs changing → confirm the specific release arrangements → get the installation entry point。
This skill is a host-agnostic shared skill, responsible for orchestrating sub-skills, controlled browser tools, and local auxiliary tools. At the start, follow Agent compatibility notes to identify the current host and verify file, terminal, browser, and sub-skill capabilities; a successful installation must not be treated as the tool being available. The first release adaptation uses Chrome / Manifest V3 as the baseline. When no browser is specified, record Chrome as a modifiable suggestion and continue working independently; when the user specifies another browser, follow that choice and separately verify that platform's rules, and must not claim that this package's Chrome checker covers them.
Execution conventions
- New projects default to formal local tasks, without requiring GitHub, a server, a paid domain, or a separate prototype. For existing projects, first read their conventions and preserve the existing task system and confirmed design.
- Proactively choose reversible technical approaches, inspect the environment, create tasks, build, troubleshoot, and verify. Reuse existing answers and authorizations, and do not make the user approve routine actions step by step.
- Check facts yourself; ask only about important unknowns that would change the purpose, data destination, costs, or distribution commitments. Explain the impact using everyday scenarios, and handle only the currently necessary questions in one round; while waiting, continue work that does not depend on the answer. Do not treat silence as confirmation for important choices.
- Tell the user "the content stays on this computer", "installation package", and "which actions have already been checked". Keep tickets, Manifest, E2E, build tools, etc. in the background; platform button names may be quoted accurately.
- Writing code, screenshots, static checks, acceptance, uploading, review, and launch each have independent evidence. For checks that have not been run, write "unverified"; do not judge as passed based on missing tools, old screenshots, or the user not reporting errors.
- Real acceptance is the delivery threshold. The first usable version, each implementation ticket, and the final release candidate package must use a controlled browser tool in the current host that has been verified to load extensions and operate native entry points, complete the end-to-end core operations and applicable close-and-reopen verification, save evidence, and pass the acceptance gate, before it can be called usable, delivery complete, or the task can be closed. Playwright MCP is the preferred reference implementation; simulating Chrome APIs, static checks, and opening the popup HTML alone cannot replace it. For specific adaptation and evidence, see Agent compatibility notes and Independent acceptance。
- When the current host lacks an available browser channel or cannot complete the real entry point, follow dependency preparation to give the specific reason, ask the user whether to install/enable or choose the recommended controlled alternative, and wait for the choice; acceptance remains
blocked, and must not silently switch to a daily browser or skip this node. Existing explicit choices are reused, and there is no item-by-item re-request for instructions. After manual assistance, it must still be connected back to real verification. Only when the user explicitly asks for source code only or requests termination may the source code be handed over within that scope and marked as unaccepted. - When lacking permission, waiting for the person's own action, or store review, save the state and explain the next step; pause work that depends on this condition. There is no actual continuous tracking capability, so do not promise background monitoring.
Product Usage Loop
When creating or changing a user flow, you must actually execute product-designer. First, according to Product Usage Loop , write entry, core actions, result handling, continued use, exit, and recovery into the existing specification. Basic operations are proactively completed by the AI; only ask the user when information on important experience trade-offs is insufficient. Final real acceptance must include repeat_use two consecutive rounds of use, with product experience review and technical results recorded separately; if the basic loop is missing, delivery must not proceed merely because technical test cases pass.
Efficiency and Wrap-up
During planning, final review, or rework, read Efficient Delivery: first verify the development environment and special browser capabilities, and list AC and hard specifications in advance; split tickets by risk and re-verify by change impact. Real evidence and dual-axis review for the same candidate may explicitly cover multiple ready work orders, but final cross-module acceptance must still be actually executed. When documentation and archiving do not change the runtime package, do not repeat product testing; once target acceptance, review, and delivery files are complete, wrap up in one pass. When the user requests an independent CLI or a complete session, preserve the actual input, replies, and original records according to that reference.
Mandatory Execution Nodes
"Execute skill" means locating and reading its real entry point and required resources, producing the corresponding results according to the process, and recording the source, input, output, and verification; merely mentioning the name, the file existing, or having read the instructions does not count as completion. Prioritize executing the following named sub-skills; if the host cannot install or invoke them, you may only use the equivalent implementation defined in Agent Compatibility Notes , and must clearly record the fallback; you must not claim that the original skill has run.
| Node | Must Execute | Completion Evidence |
|---|---|---|
| Create/change user flow and experience acceptance | product-designer |
Complete loop in the existing specification, experience AC, decision basis, and real consecutive-use review |
| Extension design, development, and release | chrome-extensions |
Actually adopted API/permission/release rules and corresponding artifacts |
| Create plugin | extension-create |
Parameters clarified, actual scaffolding and entry configuration, basic build results; do not repeat initialization for an existing project |
| Failure occurs or acceptance fails | diagnosing-bugs |
Reproduction that can determine failure, diagnosis, fix, and re-verification of the original scenario |
| Each implementation ticket and version review | code-review |
Fixed baseline, actual changes, specification, and two independent review results: standards/specification |
| First version, implementation tickets, final version acceptance | Controlled browser tool; prefer Playwright MCP | Evidence that the current artifact truly loads, native entry, complete operation, and reopening; if unsupported, the user's environment choice must be obtained |
| Complex plugin | setup-matt-pocock-skills → to-spec → to-tickets → implement |
Project conventions, published main work order, dependent child work orders, implementation by module and ticket; see Complex Plugin Orchestration |
When a required skill is missing, first follow Dependency Preparation List for the user the repositories, pinned revisions, and subdirectories that actually need to be copied for this installation, and wait for the user to explicitly say "okay" to this installation; "help me make a plugin" only authorizes creation, not copying skills from GitHub. Only after approval, install via the Skill CLI or the host installer, and do not substitute an unknown skill with a similar name. Only a portable fallback explicitly permitted by the compatibility notes may be substituted, and the actual execution method must be recorded. Technical decomposition may be completed automatically within existing authorization; alternatives when browser tools are unsupported, product commitments that cannot be inferred, and real account costs are still decided by the user.
Continue from the current project
- Determine the project directory; if
.extension-launch/already exists, first runproject.py status, then read the spec, tasks, and evidence. If another task system already exists, resume from there. Do not rebuild or overwrite tasks from chat memory. - According to Agent compatibility notes and dependency preparation , detect required skills, controlled browser tools, and development software, and record detection, reading, and execution status separately; fill in whatever is missing, and do not treat the existence of files as the capability being ready.
- The main agent judges complexity on its own and states the reason. Simple plugins use minimal local records; complex plugins must use complex plugin orchestration, with the AI issuing spec tickets, splitting tickets, and assigning independent modules.
project.py init --complexity simple|complex --complexity-reason <理由>Create a scheduling record, according to tasks and recovery linking the real spec and tickets. Based on the endpoint specified by the user, pass--goal local(use it yourself first),--goal materials(materials only), or--goal live(launch); default values are not treated as user confirmation. Out-of-scope release tasks remain not applicable and are not listed as personal to-dos. Drafted content must be filled in with facts; it is not a confirmed requirement. - Choose the next step according to the table below; at the end of each stage, the main agent summarizes progress, evidence, unresolved issues, and the next action. Do not throw the whole table at a beginner.
| Currently needed | Read and execute | Basis for progress |
|---|---|---|
| Idea or requirement changes | Tasks and recovery | Scope, data commitments, and success path are implementable; necessary answers have been recorded |
| Build or fix the first version | Development and troubleshooting | The current version actually installs, the native entry point and per-ticket features pass, with evidence and a recoverable version |
| Overall check, prepare a new version | Independent acceptance | The current candidate package passes the required real scenarios, failures have been fixed and re-verified, and the acceptance gate passes |
| Submission, rejection, launch, or update | Release and maintenance | Actual backend records and store installation results |
Local auxiliary tools
Paths are resolved relative to this skill directory. The following is for the AI to execute; replace placeholder parameters and quote paths correctly for the host, and do not make the user assemble commands. The scripts require Python 3.9+, the standard library, and no third-party Python packages. If Python is unavailable, use the host file tools according to the corresponding reference to create the same records or checks; do not claim the script has been run.
python3 <skill-dir>/scripts/project.py doctor <project-dir>
python3 <skill-dir>/scripts/project.py init <project-dir> --name <项目名> --idea <用户原话>
python3 <skill-dir>/scripts/project.py status <project-dir>
python3 <skill-dir>/scripts/release_bundle.py check <build-dir> --report <新报告路径>
python3 <skill-dir>/scripts/release_bundle.py pack <build-dir> --output <新ZIP路径> --report <新报告路径>
python3 <skill-dir>/scripts/acceptance_gate.py fingerprint <build-dir>
python3 <skill-dir>/scripts/acceptance_gate.py check <build-dir> --evidence <真实验收JSON路径> --report <新的gate-report.json路径>
doctor Only proves that a file or software was detected; it does not prove that the browser is connected.check / pack Only checks the static structure and some risks of the Chrome package; warnings must be reviewed item by item, and a successful exit does not equal real acceptance or store approval. Use --previous-version Check for updated versions; reports and ZIPs are placed outside the build directory and do not overwrite previous outputs.
Before delivery, first use fingerprint to obtain the candidate fingerprint of the current build, then fill in the real acceptance JSON according to actual operations, and finally execute the gate check and save the newly generated gate-report.json path in the task. Only gate_passed: true and with verifiable real operation records may the dependent deliverable be closed; fingerprint calculation and machine checks themselves do not prove that operations occurred. For evidence fields and invocation methods, see Acceptance Reference。
Built-in reference template is used to read or take over existing samples, and does not replace the extension-createthat must be executed for new projects. Existing projects are not copied over.
Trigger release assistance based on context
Only when the context has clearly established that the user wants store release/launch should you remind them of preparation items such as a Google account, developer registration, the first-time $5 registration fee, and internationally accepted online payment cards supported by the payment page; this is not a fixed opening stage, and you should not infer that the user wants registration and payment because of the skill name or the default goal=live. According to Release and Maintenance , assist in the built-in browser with filling in the name, description, images, and promotional materials that the user has already provided or explicitly adopted. When material generation is unavailable, stop at the material step and ask the user to upload before continuing; do not pass with placeholder images.
Delivery to the user
Deliver the result that has passed real acceptance and brief operating instructions, clearly stating how far it has been done, on what basis, and what the user still needs to do personally. Authorized work continues to be advanced to the specified endpoint; if the required real acceptance has not passed, continue fixing or filling in missing capabilities, and when there is an actual external blocker, leave a blocked status and a recoverable record, without claiming a usable deliverable is complete.
- First version: the directory that has actually been installed and accepted from the native entry point, core operation results, applicable reopening persistence evidence, and limitations. Feedback directly revises this version, with no default prototype review.
- Release preparation: after extracting the final ZIP, real acceptance passing and the gate report, real screenshots and icons, paste-ready copy, permission data explanation, necessary public links, and specific distribution and release arrangements. Handle missing authorization only after the materials are ready; do not use 'want to launch' to fill in unconfirmed identity declarations or fee choices.
- During review: the actual submission record, current status, and who will check next and in what way. Do not describe uploading as submitting or launching.
- Launch complete: the store entry point where target users can install, the matching version, evidence that first use after installing from the store passed, usage instructions, and a feedback entry point. Plugin users do not need this skill or a development environment.
The rules were distilled from the three research documents provided with the requirements; the package does not depend on the original author's computer directory or StyleSnip private tickets. Official factual entry points and verification dates are in the release reference.