How do I install the Index365 Apply Fix skill?

Run npx skillmds@latest add index365usa/index365-apply-fix in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Index365 Apply Fix safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Index365 Apply Fix?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Index365 Apply Fix free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Index365 Apply Fix?

index365usa (@index365usa) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Index365 Apply Fix by index365usa — Agent Skill

Name: Index365 Apply Fix
Author: index365usa

Index365 Apply Fix

Use when the user wants to fix a single index365 finding in this repository. Triggers: "fix this finding", a pasted `findingId` (e.g. `f_ab12cd34`), the "copy fix prompt for your agent" button from the dashboard, "apply the index365 fix for…", or "resolve this one issue". One finding, one focused diff. For the whole report at once, use index365-audit-and-fix.

index365usa Updated Sep 17, 2026

File contents

index365 apply fix

Apply one finding's fix in the current repo and show the diff. You need to be in the repository that serves the audited site; the finding itself comes from the latest run, no ids to carry.

Workflow

Get the finding's full detail (prefer the machine-readable fix):
```
index365 findings get 1 --json        # by ordinal from the findings table
index365 findings get f_ab12cd34      # or by a pasted findingId
```
Read agentActions first, it is the product's own machine-readable remediation. Fall back to the human remediation text only if agentActions is absent. Note affectedUrls. The non-JSON form also prints a copy-pasteable fix prompt (--prompt prints only the raw prompt, for piping).
Map the affected URL to a file. Use Glob/Grep over the repo to find the route, component, template, or config that produces each affectedUrl.
Honor the user's application boundary. If the user asked to preview, propose, or approve the change before application, produce the smallest proposed patch without editing files, show it, and stop for approval. Otherwise, the user's direct fix/apply request authorizes one logical Edit that resolves exactly this finding. Match the surrounding code's style. Do not refactor or fix unrelated things.
Show the result. For preview-only work, label the patch proposed and do not claim the repository changed. For an authorized edit, show the actual diff and state which findingId it resolves.
Verify only after application by re-scanning the same site (same --product as the original run, if it was Marketing Signal):
```
index365 scan yoursite.com --yes --idempotency-key "verify-f_ab12cd34-1"
```
The idempotency key makes a retry of this verification safe without double-spending; use a fresh key per verification, never one from an earlier scan, which would replay that earlier run instead of measuring the fix. Then index365 findings reads the new run: confirm the finding is gone by matching its stable findingId (ordinals can shift between runs). A proposed patch is not eligible for re-run proof. A fix that doesn't move the score isn't done.

STOP and ask the user when

The fix would exceed what the finding describes (scope creep).
affectedUrls doesn't resolve to any file in this repo (it's an out-of-repo or infra/DNS/hosting fix, report it, don't invent a code change).
The remediation requires a product/brand/content decision rather than a mechanical edit.
The user requested a proposed diff or approval before application. Stop after the proposed patch and wait; do not call Edit or re-scan yet.

Don't

Don't re-derive a fix when agentActions already specifies it.
Don't batch several findings here, that's index365-audit-and-fix.
Don't claim it's fixed without a re-scan or a monitor diff.

---name: index365-apply-fixdescription: Use when the user wants to fix a single index365 finding in this repository. Triggers: "fix this finding", a pasted `findingId` (e.g. `f_ab12cd34`), the "copy fix prompt for your agent" button from the dashboard, "apply the index365 fix for…", or "resolve this one issue". One finding, one focused diff. For the whole report at once, use index365-audit-and-fix.---# index365 apply fixApply one finding's fix in the current repo and show the diff. You need to be in therepository that serves the audited site; the finding itself comes from the latestrun, no ids to carry.## Workflow1. **Get the finding's full detail** (prefer the machine-readable fix): ```bash index365 findings get 1 --json # by ordinal from the findings table index365 findings get f_ab12cd34 # or by a pasted findingId ``` Read `agentActions` first, it is the product's own machine-readable remediation. Fall back to the human `remediation` text only if `agentActions` is absent. Note `affectedUrls`. The non-JSON form also prints a copy-pasteable fix prompt (`--prompt` prints only the raw prompt, for piping).2. **Map the affected URL to a file.** Use `Glob`/`Grep` over the repo to find the route, component, template, or config that produces each `affectedUrl`.3. **Honor the user's application boundary.** If the user asked to preview, propose, or approve the change before application, produce the smallest proposed patch without editing files, show it, and stop for approval. Otherwise, the user's direct fix/apply request authorizes one logical `Edit` that resolves exactly this finding. Match the surrounding code's style. Do not refactor or fix unrelated things.4. **Show the result.** For preview-only work, label the patch `proposed` and do not claim the repository changed. For an authorized edit, show the actual diff and state which `findingId` it resolves.5. **Verify only after application** by re-scanning the same site (same `--product` as the original run, if it was Marketing Signal): ```bash index365 scan yoursite.com --yes --idempotency-key "verify-f_ab12cd34-1" ``` The idempotency key makes a retry of this verification safe without double-spending; use a fresh key per verification, never one from an earlier scan, which would replay that earlier run instead of measuring the fix. Then `index365 findings` reads the new run: confirm the finding is gone by matching its stable `findingId` (ordinals can shift between runs). A proposed patch is not eligible for re-run proof. A fix that doesn't move the score isn't done.## STOP and ask the user when- The fix would exceed what the finding describes (scope creep).- `affectedUrls` doesn't resolve to any file in this repo (it's an out-of-repo or infra/DNS/hosting fix, report it, don't invent a code change).- The remediation requires a product/brand/content decision rather than a mechanical edit.- The user requested a proposed diff or approval before application. Stop after the proposed patch and wait; do not call `Edit` or re-scan yet.## Don't- Don't re-derive a fix when `agentActions` already specifies it.- Don't batch several findings here, that's **index365-audit-and-fix**.- Don't claim it's fixed without a re-scan or a monitor diff.

Frequently asked questions