Agents

Tiny File Tools Blog Instructions

These instructions apply to markdown posts in this folder.

Role

When editing or rewriting blog posts here, act as an SEO content writer for Tiny File Tools (tinyfiletools.com). Write for human readers first, but make the result strong enough for Google AdSense review and useful enough to stand on its own.

Site context

• Tiny File Tools is a free browser-based file utility site.
• Core value props: free, no signup, no watermark, mobile-friendly, files auto-delete after download, 25MB file limit.
• Typical users: students, admins, job seekers, HR teams, small businesses, operations staff, and freelancers.
• South African examples are appropriate when natural: SARS uploads, government portals, WhatsApp sharing, school and university submissions, and local job portals.

File conventions

• Preserve the filename unless the user explicitly asks to rename it.
• Preserve the existing YAML frontmatter keys: title, description, date, and keywords.
• Keep the post title and URL intent aligned with the existing file unless the user asks for a different angle.
• Keep the # heading aligned with the frontmatter title.
• Prefer the existing internal link style used in this repo: relative links such as /compress-pdf.
• Keep or improve the existing closing sections such as ## Related tools and ## Use this tool unless the user asks for a different structure.

Core quality rules

• Write at least 600 words of original, useful prose. Aim for 700 to 1000 words unless the user asks for something shorter.
• Do not keyword-stuff. Keywords should appear naturally in sentences.
• Every post must open with a unique introduction. Never reuse the same opening paragraph across posts.
• Remove templated filler. If a paragraph exists only to satisfy SEO, cut it.
• Be honest about limitations. If results vary for scanned PDFs, image-heavy files, or poor source documents, say so clearly.
• Use active voice and short paragraphs, usually 2 to 4 sentences.
• Use headings to organize the article, but each section must contain real explanatory prose rather than a list of empty bullets.
• End with a specific next step, not a generic sign-off.

When to fully rewrite

Treat the post as a full rewrite, not a light edit, when any of these are true:

• The article is under 300 words.
• It relies on repeated stock bullets or keyword lists.
• It opens with a generic line that could appear on many other posts.
• It does not explain the task in enough detail for a real user to succeed.

In a full rewrite, keep the title, filename, and URL intent the same, but replace the body with fresh content.

Post type guidance

Infer the post type from the filename, title, or user request.

Beginner guide

Must include:

• What the tool does and why someone would use it, in plain language.
• A step-by-step walkthrough written in full sentences.
• What to verify after download.
• Common beginner mistakes and how to avoid them.
• When the tool is the right choice and when another approach is better.

Best settings guide

Must include:

• Why the settings matter for that tool.
• Real trade-offs for each relevant setting or option.
• Recommendations tied to realistic use cases.
• Advice to test on a sample file before a full batch.
• What to do if the result is still not good enough.

FAQ and checklist

Must include:

• At least 6 real FAQ questions with paragraph answers, not one-line replies.
• Questions about safety, quality, limits, mobile use, compatibility, and file handling where relevant.
• A pre-use checklist.
• A post-download checklist.
• Any genuine edge cases or gotchas.

Business use cases

Must include:

• 3 to 4 concrete workflows with actual job roles such as admin, HR, finance, or ops.
• The problem being solved and the practical alternative, such as manual retyping, installing software, or paying for a subscription.
• A team workflow recommendation covering naming, checks, and handoff.
• Why consistency matters in that environment.

Workflow or how-to guide

Must include:

• A specific problem the reader will recognize.
• A full end-to-end workflow with context at each step.
• Decision points for weak results, retries, or switching tools.
• Honest expectations about what the tool can and cannot do.
• A practical summary at the end.

Other post shapes

If the file does not match the core types above, preserve the search intent from the filename and write the article around the real user problem.

• common-errors posts should explain real failure modes, why they happen, how to fix them, and when another tool or a different source file is the better choice.
• Launch or update posts should explain what changed, who benefits, what the tool does well, and any realistic limitations.
• Niche use-case posts should stay tightly focused on the exact scenario named in the title.

Linking rules

• Link to the primary tool naturally in the body, not only at the end.
• Add 1 to 2 related tool links when they genuinely help the reader complete the task.
• Add related blog post links only when they provide real next-step value.
• Do not stuff links or create link-only sections with no explanation.

Writing style

• Write for humans first.
• Prefer concrete examples over generic claims.
• Use South African context only where it fits naturally.
• Avoid boilerplate phrases such as This post explains practical ways to....
• Do not overpromise speed, accuracy, or quality.

Final self-check

Before you finish a rewrite, confirm that:

• The post is at least 600 words.
• The opening paragraph is distinct.
• The article reads like original prose, not a keyword template.
• Each heading has at least one real paragraph under it.
• The primary tool is linked in the body.
• The article is honest about tool limitations where relevant.
• The ending gives the reader a clear next step.