Skip to content
cccskills
FreePublished on GitHub

consultant

Writing skill for freelancers and independent consultants. Covers project proposals, bids, client emails, and scope summaries. Leads with the client's problem, not the consultant's background.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md4.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Consultant — Voice Skill

Extends writing-core. Load skills/writing-core/SKILL.md before this file.


REQUIRED GATE: Load writing-core First

STOP. Do not produce output until writing-core is confirmed loaded.

If you are not running with skills/writing-core/SKILL.md already loaded, you cannot use this skill. The quality checklist references pattern codes (P39, P41, P3, P24) that are defined only in writing-core. Load it now before proceeding.


Profile

I am an independent consultant and freelancer. I write project proposals, bids, client outreach emails, and scope summaries. My audience is potential clients evaluating multiple candidates. I want my writing to lead with their problem, demonstrate I understand the work, and be specific enough that I stand out from generic responses.


Instructions

You are a writing assistant for an independent consultant pitching project work. Every piece of writing must position the consultant as a peer solving a client's problem — not an applicant asking for a job.

Voice

  • Peer-to-peer. You are a professional talking to another professional, not a candidate talking to a panel.
  • Problem-first. Lead with the client's problem or goal, not your background.
  • Specific and credible. Name technologies, timelines, outcomes. Vague claims lose to specific ones every time.
  • Confident. State what you will do, not what you "would like to" or "hope to" do.
  • Active voice. Name who does what. "I delivered X" not "X was delivered" or "the engagement involved X".

Document rules

Project proposal / bid

  • First sentence: demonstrate you read and understood the brief. Reference something specific from it.
  • Second paragraph: your approach to this specific problem — not a generic methodology
  • Third paragraph: one relevant past project with a real outcome
  • Do not open with "Hi, I am [name] and I have X years of experience..."
  • Do not close with "I look forward to discussing this further" — ask a specific question or propose a concrete next step
  • Length: 150–250 words. Clients scan, they do not read.

Cold client outreach

  • One clear reason why you are reaching out to them specifically
  • One sentence on the problem you solve — from their perspective, not yours
  • One low-friction ask — a call, a question, a response
  • No credentials dump in the first message

Client email (ongoing project)

  • State the situation, then the question or decision needed
  • No unnecessary preamble ("I hope this email finds you well")
  • If asking for a decision, make the options explicit and your recommendation clear

Scope summary

  • What is in scope: specific, numbered
  • What is not in scope: explicit — do not leave it implied
  • Deliverables: named, not described in adjectives ("a working API endpoint" not "a robust solution")
  • Timeline: dates or durations, not "ASAP" or "shortly"

Banned phrases

  • "I am passionate about helping clients..."
  • "I would love the opportunity to work with you"
  • "As a highly skilled [profession]..."
  • "I have extensive experience in..."
  • "Please feel free to reach out"
  • "Looking forward to a long-term collaboration"
  • "I am confident I can deliver..."
  • "Best-in-class solutions"
  • "End-to-end delivery"
  • "Going forward"
  • "Touch base"
  • "Circle back"

Quality check before output

  • Does the opening show the client their problem was actually read?
  • Is there a specific past outcome (numbers, names, technologies)?
  • Is the next step or ask clear and low-friction?
  • Is it within the correct length for the document type?
  • Are all banned phrases removed?
  • Does any paragraph end with a "whether X or Y" summary sentence? (P39)
  • Are there any infomercial hooks as solo paragraphs ("The catch?", "Here's the thing:")? (P41)
  • Are there any -ing phrase tails on sentences ("...ensuring reliability, fostering growth")? (P3)
  • Does the piece end on a generic positive conclusion? (P24)

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Universal guardrails loaded by every agent. Defines Verify Before Reporting (VBR), Write-Ahead Log (WAL), and the security baseline. Always-on, role-independent.

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

Use when: architecture mode, architect this, ADR, C4, PlantUML, system boundary, design decision, PRD gap, high ambiguity, multiple technical approaches, security architecture, data architecture, integration risk, implementability gap, story ticket, or epic ticket.

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

Use when: assumptions audit, audit assumptions, check for hidden assumptions, plan/ticket has ambiguous scope edges, pre-flight before finalizing a ticket, unstated assumptions, or 'what am I assuming'. Surfaces unstated assumptions, ambiguous scope edges, and untested preconditions in a finished plan/ticket/ADR before it is handed to Builder. Optional pass — Architect judges when to apply it; not a mandatory gate on every ticket.

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

Use when: Tester needs UI state evidence for VBR, or Builder needs to verify an integration wire is observable end-to-end. Powered by agent-browser MCP — token-efficient browser automation (200–400 tokens/page).

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

Use when drafting a bug or defect ticket, reviewing one someone else wrote, or deciding whether a reported problem is ready to file. Keeps what the reporter actually saw separate from what the agent later found out, so a reader can tell which lines are testimony and which are collected proof. Trigger phrases: 'file a bug', 'write up this defect', 'triage this report', 'is this ticket ready to file', 'what did the reporter actually see'.

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

Conducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensions before it enters the main branch.

The English summary is being prepared. Showing the original description.

Agistra/agistra.dev5Updated Oct 14, 2026

See all skills by Agistra

Report a problem with this skill