Borrowing it
Nothing to install: this file belongs to minorcell/aquaregia. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/minorcell/aquaregia/main/.agents/skills/writing-proposals/SKILL.mdgit clone --depth 1 https://github.com/minorcell/aquaregiaWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/minorcell/aquaregia/writing-proposals)<a href="https://agentmods.dev/skills/minorcell/aquaregia/writing-proposals"><img src="https://agentmods.dev/badge/skills/minorcell/aquaregia/writing-proposals/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/minorcell/aquaregia/writing-proposals"><img src="https://agentmods.dev/badge/skills/minorcell/aquaregia/writing-proposals.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00060 | $0.01861 |
| Opus 5 | $0.00030 | $0.00931 |
| Sonnet 5 | $0.00012 | $0.00372 |
| Haiku 4.5 | $0.00006 | $0.00186 |
Grade A, and why
writing-proposals scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
Copies of this mod
1 near-identical copy found in the catalogue:
- writing-proposals — 91% identical, 1 lines differ
How it starts
The opening of the file, as written. The whole thing — 253 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Writing Proposals
Overview
Write proposals as small, reviewable design increments. The goal is not to describe a whole system at once; the goal is to isolate the next necessary design decision, express it simply, remove avoidable complexity, define boundaries, and ground the change in real user stories.
A good proposal makes a reviewer able to decide, an implementer able to build, and a maintainer able to verify. Format is secondary to this thinking model.
Core Thinking Model
1. Design Progressively
One proposal should settle one clear increment. Do not try to explain every related subsystem, future extension, or complete architecture in a single proposal.
Use follow-up proposals for adjacent decisions. Prefer a narrow proposal that can be accepted, implemented, and tested over a broad proposal that tries to solve the whole future.
2. Prefer Simple, Direct Expression
Choose the expression a reader can understand immediately. If one realistic example explains the design, lead with the example before abstract definitions. If one rule can explain the behavior, do not introduce multiple mechanisms.
The design should be short, teachable, implementable, and easy to remember.
3. Do Subtractive Design
The proposal should reduce redundancy or accidental complexity. Look for opportunities to remove:
- boilerplate code
- manual steps
- repeated configuration
- exposed intermediate mechanisms
- special cases users must remember
- duplicated concepts across similar workflows
Do not add features for completeness. Add the smallest design that lets the system absorb repeated work or remove unnecessary user burden.
4. Define Boundaries Carefully
Make the limits explicit:
- what this proposal solves
- what it does not solve
- which cases are valid
- which cases are errors
- whether existing behavior changes
- what workaround exists today
- where this design meets existing mechanisms
Clear boundaries prevent a proposal from expanding into a large system design.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 253 lines · 60 tokens per session scan A 29e7ca1ceb21
writing-proposals is a skill published in the GitHub repository minorcell/aquaregia (11 stars, last pushed 21d ago), licensed MIT. It adds 60 tokens to every session and 1,861 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
html-artifacts
Author the HTML for a plan artifact, dashboard iframe, or Slack attachment — structure, design plan, available runtime, theming, and craft. Read this before writing HTML for saveplan, outputiframe, or slackattachhtml.
bootstrap-repo-analysis
First-time analysis of a repository with no prior reviewer outcomes. Crawl historical merged-PR review feedback with the gh CLI (plus any preloaded samples), extract the team's review norms, and synthesize the initial per-repo review-style prompt. Use this for a cold-start repo; use continual-learning instead once the…
baby-sit
Monitor a GitHub pull request until CI is green, diagnose failures, and rerun only evidence-backed flaky GitHub Actions jobs.
environments
How Open SWE environments work and how to change them — create one, edit or fork an existing one, start from scratch, what setupscript and updatescript are for, why a nightly refresh failed, where the build logs are, and how to read a rebuild in progress. Read this whenever someone asks about environments, snapshots…
continual-learning
Nightly refinement of an existing per-repo review-style prompt using this reviewer's own finding outcomes. Read confirmed (resolved-by-commit / thumbs-up) and dismissed (thumbs-down) findings, promote the bug patterns the team actually fixes, demote the false-positive patterns, reconcile against the current prompt…
activity-record
Query and orchestrate Arkloop Activity Record local activity data. Covers browser history, search terms, screen time, bluetooth, shell commands, window focus, keyboard, mouse, clipboard, screen content (accessibility tree), microphone audio transcription, and Codex sessions.