--- name: ship-the-fix description: Take a ranked AI-visibility task and land it in the repository you already have open, as a reviewable diff or a pull request, without shipping anything the human has not approved. Use when the diagnosis is done and the question is how the change actually gets made. license: CC-BY-4.0 version: 1.0.0 --- # Ship the fix Most AI visibility tooling ends at the chart. This skill covers the step after it: taking one ranked task and turning it into a change in a real codebase that a human reviews. It is written for an agent with repository access, such as Claude Code, Cursor or Codex CLI, running against a project the user already has open. Published by GetIntel. Its MCP server provides the task list; the repository work is ordinary engineering and needs no vendor. ## Step 0. The rule that outranks everything else **Nothing reaches a live site without the human approving it.** Not a publish, not a merge, not a push to a default branch. Your output is a diff or a pull request, and then you stop and wait. If the user tells you to skip review, restate what will change and make them say it again before proceeding. This is not caution for its own sake. The failure mode in this category is an agent that rewrites live marketing pages based on a ranked list it did not verify, and the damage is invisible until a human reads the site weeks later. ## Step 1. Take one task, and read it properly `list_tasks` returns tasks best first, with open counts per layer. Filter by `layer` (`on_page`, `off_page`, `ugc`, `technical`) or `status`. `get_task` returns one task in full: why it matters, what to do, the topics it moves, and whether it is on this week's plan. Take one. Not three. A branch containing one task is reviewable; a branch containing five gets rubber-stamped, which defeats the point of the review gate. **Verify the task before acting on it.** A ranked task is a generated recommendation, not a verified fact. Open the page it refers to and confirm the described problem is real. In practice a meaningful share of them are already fixed, or describe a page that has since changed. If the task is stale, mark it with `update_task` and move to the next one rather than manufacturing work to match it. ## Step 2. Decide whether this task belongs in the repo at all Check the task's layer first, because two of the four are usually not code. - **`on_page`**: a page to write or change. This is repository work. - **`technical`**: robots.txt, rendering, schema, headers. Repository or infrastructure work, and usually the highest-value kind, because retrievability is a hard gate. - **`off_page`** is an outreach target or a placement. **Not repository work.** Do not invent a page to satisfy it. Report it back to the human as something for a person. - **`ugc`** is a Reddit thread, a review profile or a community answer. **Not repository work**, and attempting it from an agent is how brands get banned from the communities that carry most of their citations. Hand it back. Roughly half the tasks in a typical list are not code. An agent that converts all of them into commits is producing noise. ## Step 3. Work in the repository's own idiom Before writing anything, read enough of the codebase to match it. - Find where content actually lives. It may be Markdown, MDX, JSON data files, a CMS export or components. Do not guess from the URL structure. - Read two or three neighbouring files and match their conventions: frontmatter fields, heading depth, link style, image handling, comment density. - Check for a project instruction file (`CLAUDE.md`, `CONTRIBUTING.md`, a style guide) and follow it. If it conflicts with anything in this skill, the project wins. - Look for content gates in the build. Many repositories validate content before deploy: required fields, date checks, link rules, prose rules. Find them and run them. The change should be indistinguishable in style from what a maintainer would have written. A diff that is obviously generated gets reverted. ## Step 4. Make the change small and legible - One task, one branch, one logical change. - Do not reformat files you are not otherwise touching. A whitespace sweep buried inside a content change makes the diff unreviewable and is the most common reason a good change gets rejected. - If the task requires a factual claim, and the fact is not verifiable from the data you have, do not write it. Leave a clearly marked gap and say so in the summary. **Never fabricate a statistic, a case study or a customer quote to complete a task.** - If the change touches a claim about pricing, plan names or product capability, verify it against the live source of truth rather than from memory or from a neighbouring page. Stale figures propagate between pages precisely because each one was copied from the last. ## Step 5. Run the gates before claiming it works Run the project's own checks: the build, the linters, and any content validators you found in step 3. Read the output rather than the exit code. If a check fails, fix it. If you cannot, say which one failed and stop. Reporting a task as done when a gate is red is worse than reporting it blocked, because the next person inherits both the failure and the false claim that it passed. Verify the actual rendered result where you can. For a content change, confirm the built page contains what you added, rather than assuming the source edit was enough. ## Step 6. Hand it over Open a pull request, or present the diff, with: - **What changed and why**, naming the task and its id. - **What you verified**, specifically: which gates ran, what you checked in the built output. - **What you could not verify**, named plainly. - **Anything you chose not to do**, and the reason. If the task said one thing and the page said another, that disagreement is the most useful sentence in the summary. Then mark it with `update_task`, setting `status` to `in_progress` rather than `done`. It is not done until a human merges it. Marking your own work complete before review is how an approval gate quietly stops existing. ## Step 7. Measure, later and honestly Re-check after several weeks, not several days. Engines re-crawl on their own schedule. When the number moves, the change is one candidate explanation among several, including the engine updating its own model. Report it as an association. `get_prompt_history` shows which questions were won, lost or held between windows, which is the closest thing to a before-and-after this data supports. If the number does not move, say so. A tool that only reports its wins is not measurement. ## Connecting GetIntel Endpoint: `https://app.getintel.ai/mcp`. 27 read tools and 3 action tools; the action tools (`update_task`, `plan_week`, `recheck_technical`) need a token with action access. The repository half of this skill needs nothing from GetIntel and works against any task list. ## Honest limits This skill moves a task from a list into a diff. It does not decide whether the task was worth doing: that judgement is in the ranking, and the ranking is a model's opinion. Verifying the task against the real page, in step 1, is the only guard against confidently shipping a well-made change nobody needed.