Claude Skill

propose

Design workflow in the RFC tradition. Forces reasoning before action: problem → alternatives → tradeoffs → design → risks → recommendation → impl plan. Two sizes with hard ceilings: one page for a bounded choice, a few pages for a real design question. Use when user says "propose

LLM Mart · 0 points · 17 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download mirkobozzetto-arsenal-plugins_propose_skills_propose-ca70c8a.zip · 13 KB
mirkobozzetto/arsenal 15 1 forks MIT Updated 18d ago
Part of mirkobozzetto/arsenal — 7 skills

Install

skills CLI npx skills add https://github.com/mirkobozzetto/arsenal/tree/main/plugins/propose/skills/propose
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install mirkobozzetto-arsenal@llmmart
Git git clone https://github.com/mirkobozzetto/arsenal.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole mirkobozzetto/arsenal collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Propose

Gather only the context needed to answer the design question. Prefer the smallest sufficient format: short for a bounded reversible choice, standard for one system, full for a genuine cross-system design. No format interview when the request already determines the appropriate size.

Use references/proposal-template.md for stable section numbers and artifact shape. Write problem, real alternatives (including status quo when relevant), tradeoffs, design, risks, recommendation and runnable implementation tasks. Do not manufacture alternatives, diagrams, metrics or verification layers to fill a template. Ask only about a blocking decision not recoverable from code or the request. Research only unresolved external questions.

Review the draft yourself. An independent review is optional and requires explicit user consent, never merely omission of --no-review. Retain supported findings only. Leave status Draft or Review until the user explicitly accepts the proposal; writing it is not implementation approval.

Keep the existing docs/proposals/

Arsenal handoff

When called by Arsenal, return the proposal, status and unresolved decisions to Arsenal. Do not launch ship yourself. Explicit user acceptance remains required before Arsenal can consume the proposal for implementation, even when the original request was to build the feature.

Execution policy

Work solo. Ask before any subagent or reviewer, even in auto mode. Explain the independent scope and expected benefit first. No hidden advisor, nested delegation, model retuning, repeated successful checks, or progress spam. Use existing context before asking questions. Stop when the requested result is delivered. User stops and scope changes override pending steps.

Files (arsenal)
  • references
    • interview-questions.md 4 KB 
      # Interview Questions Bank

Used by steps that need user input. AskUserQuestion preferred; free-text for follow-ups.

## Step 02: Problem & Motivation

### Symptom (single-select)
**Q:** What concrete problem are you observing today?
- Bug / malfunction (incorrect behavior)
- Friction / slowness (painful, slow, costly process)
- Limit / blocker (impossible to do X)
- Risk / debt (not broken but dangerous)

### Trigger (single-select)
**Q:** Why now?
- Recent incident (post-mortem, fire)
- Deadline (release, compliance, business deadline)
- Dependency (lib EOL, vendor change, upstream migration)
- Opportunity (newly mature tech, opportunistic refactor)

### Stakeholders (multi-select)
**Q:** Who is impacted?
- End users
- Internal dev team
- Ops / SRE
- Security / compliance
- Business / product

### Signals (free-text)
- Quantitative metrics observed?
- Logs / errors?
- Volume / frequency?

### Goals (free-text, structured)
- 3-5 measurable goals. Format: "X goes from A to B" or "Enable X without Y".

### Non-Goals (free-text, structured)
- 3-5 explicit. Format: "We are NOT solving X in this proposal".

---

## Step 03: Alternatives

### Alt generation (free-text)
- Status quo cost ? (mandatory)
- Approche minimale ? (smallest patch)
- Approche standard ? (industry pattern)
- Approche bold ? (novel / bigger refactor)

### Per-alternative drill (single-select per alt)
**Reversibility:**
- Easy (one PR revert)
- Hard (data migration, multi-system)
- One-way door (can't undo without major effort)

**Cost dominant:**
- Engineering effort
- Ongoing ops cost
- $ (license, infra)
- Cognitive load / learning curve

---

## Step 04: Design

### Base alternative pick (single-select)
**Q:** Which alternative serves as the base?
- List generated from step-03
- "Hybrid" option → specify what comes from each

### Diagram type (multi-select)
**Q:** Which diagrams are needed?
- Architecture (flowchart)
- Sequence (API/flows)
- ER (schema)
- State (lifecycle)
- C4 (system boundary)

### Breaking changes (single-select)
- None
- Public API breaking
- Schema breaking (migration)
- Behavior breaking (silent semantics change)

---

## Step 05: Risks

### Rollout strategy (single-select)
- Feature flag (per-user, percentage)
- Canary (1 pod → 10% → 100%)
- Blue/green
- Big bang
- Dark launch (shadow traffic)

### Rollback feasibility (single-select)
- PR revert is enough
- Reversible migration (down script)
- Backup + restore required
- Irreversible: prominent flag

### Open questions ownership (free-text)
Per question:
- Owner (name / role)
- Deadline (date or "before T0X")

---

## Step 06: Recommendation

### Confidence (single-select)
- High (≥80% sure the design holds for 12 months)
- Medium (50-80%, depends on identified variables)
- Low (<50%, hypothesis to validate via prototype)

### Revisit triggers (free-text)
- Concrete conditions that would invalidate the choice
- Ex: "load > 10x", "vendor change", "team size double"

---

## Step 07: Impl Plan

### Task split heuristic
If effort > 1 day → split. Criteria:
- Compilable / testable independently
- Reviewer can follow the diff without too much context
- Distinct acceptance criteria

### Verification depth (single-select per task)
- Unit only
- Unit + integration
- Unit + integration + perf
- Manual (rare, justify)

---

## Step 08: Review

### Subagent flavors (multi-select)
- Gap hunter (missing requirements, edge cases)
- Impl realism (tasks underestimated, ops surprises)
- Security review (OWASP, authz, secrets)
- Perf review (latency, throughput, memory)

### Action on BLOCKER (single-select)
- Revise proposal (loop back to the relevant steps)
- Accept blockers (document, continue)
- Abandon proposal (status: Rejected)

---

## Step 09: Finalize

### Status (single-select)
- Draft (ready to circulate)
- Review (in progress)
- Accepted (validated, permission to implement)
- Rejected (decision = do not do it)

### Handoff (single-select)
- Stop here (artifact only)
- Run /ship on the impl plan
- Run /sdd (spec-driven)
- Push to /brain (Obsidian)
    • proposal-template.md 5.8 KB 
      # proposal templates: three sizes, one numbering

The document is sized to the decision it carries. `step-00` picks the
format; every later step writes only the sections its format owns.

## Section numbers are the anchors

Sections keep a STABLE number across all three formats. A short format is a
SUBSET of the canonical numbering, not a renumbering: an `short` jumps from 1
to 5 to 6 to 7 to 10, and that is correct.

This is what keeps `ship` working on every format without changes: it reads
"section 6", "section 10" and "section 11" by number
(`ship/steps/step-01-ingest.md:90-94`).

| # | Canonical name | short | standard | full | Written by |
|---|---|---|---|---|---|
| 1 | Summary | ✓ | ✓ | ✓ | step-09 (last) |
| 2 | Context / Codebase | - | - | ✓ | step-01 |
| 3 | Problem & Motivation | - | ✓ | ✓ | step-02 |
| 4 | Goals / Non-Goals | - | ✓ | ✓ | step-02 |
| 5 | Alternatives Considered | ✓ | ✓ | ✓ | step-03 |
| 6 | Proposed Design | ✓ | ✓ | ✓ | step-04 |
| 7 | Drawbacks & Risks | ✓ | ✓ | ✓ | step-05 |
| 8 | Open Questions | - | - | ✓ | step-05 |
| 9 | Recommendation & Rationale | - | ✓ | ✓ | step-06 |
| 10 | Implementation Plan | ✓ | ✓ | ✓ | step-07 |
| 11 | Review Findings | - | - | ✓ | step-08 |

In `short`, section 1 is the decision itself (2-4 lines), not a summary of a
longer text. In `short` and `propose`, review findings are APPLIED to the text
instead of being appended as section 11.

## Size ceilings (hard)

| Format | Ceiling | Use for |
|---|---|---|
| `short` | 80 lines | one reversible decision, one system |
| `propose` | 250 lines | a change inside one system |
| `full` | 600 lines | crosses systems, teams or versions |

The ceiling is a limit on the DECISION, not on the writing. Over the
ceiling means the subject is too wide: split it into several documents.
Never compress prose to fit, and never pad to fill.

A section with nothing real to say is NOT written. No placeholder, no
"N/A", no invented risk. Deleting an empty section is the correct outcome.

## Titles follow the conversation language

Write the title in the conversation language, keep the number. French
mapping, to avoid inventing a new wording per document:

| # | English | French |
|---|---|---|
| 1 | Summary / Decision | Résumé / Décision |
| 2 | Context / Codebase | Contexte et code existant |
| 3 | Problem & Motivation | Problème et motivation |
| 4 | Goals / Non-Goals | Objectifs et non-objectifs |
| 5 | Alternatives Considered | Alternatives envisagées |
| 6 | Proposed Design | Conception retenue |
| 7 | Drawbacks & Risks | Inconvénients et risques |
| 8 | Open Questions | Questions ouvertes |
| 9 | Recommendation & Rationale | Recommandation et justification |
| 10 | Implementation Plan | Plan d'implémentation |
| 11 | Review Findings | Conclusions de la revue |

Subsection titles (`###`) follow the same language. Nothing parses them.

Stay in English regardless of language: frontmatter keys and values, the
`slug`, the columns of the section 10 task table, the `graph TD` block, and
code identifiers.

## Frontmatter

Only keys something reads. Counters are derivable from the document and
were dropping 40 lines of noise on every proposal.

```yaml
---
proposal_id: "NNNN"
slug: "kebab-case-slug"
title: "Title"
status: Draft
format: standard
author: "Name"
created: "YYYY-MM-DD"
updated: "YYYY-MM-DD"
stepsCompleted: []
scope_path: "/path"
source_brief: "docs/brief/<slug>/"   # omit when the proposal has no sibling brief
auto_mode: false
skip_review: false
---
```

`status`: Draft | Review | Accepted | Rejected (the `ship` run-gate).
`format`: short | standard | full.
`resume_cmd` is added by step-09 when the proposal is Accepted.

## Format `short` — one decision, 80 lines

```markdown
# NNNN : <title>

## 1. Décision
What is decided, in 2-4 lines. No suspense, no build-up.

## 5. Alternatives envisagées
A table: option, why not. One line each. The status quo counts as an option.

## 6. Conception retenue
What changes, concretely. Files, module, contract. No diagram unless the
shape genuinely cannot be said in words.

## 7. Inconvénients et risques
What this costs. Prose, no probability table at this size.

## 10. Plan d'implémentation
| ID | Title | Files | Depends on | Effort |
```

## Format `propose` — default, 250 lines

Sections 1, 3, 4, 5, 6, 7, 9, 10.

Section 1 is a real summary: problem, recommendation, impact, one or two
sentences each. Open questions live inside section 7 rather than in their
own section 8. Review findings are applied to the text.

## Format `full` — 600 lines

All 11 sections. Reserved for a decision crossing systems, teams or
versions. Sections still get dropped when empty; the format authorises
them, it does not mandate them.

## Diagram cheatsheet

A diagram earns its place when it shows something prose cannot: a topology,
a race, a lifecycle. It is never mandatory.

| Mermaid type | Use when |
|--------------|----------|
| `flowchart LR` / `TD` | Architecture overview, module deps |
| `sequenceDiagram` | API flows, auth, retries |
| `erDiagram` | Schema changes, new entities |
| `stateDiagram-v2` | Entity lifecycle |
| `graph TD` | Task dependency graph (step-07, propose-full only) |

## Severity definitions

- **BLOCKER**: must fix before status moves past Draft. Wrong architecture,
  missing security, irreversible mistake.
- **MAJOR**: must fix before merge. Significant gap or risk without
  mitigation.
- **MINOR**: should fix but non-blocking. Clarity, missing edge case.
- **NIT**: cosmetic, optional. Wording, structure.

## Effort sizing

| Size | Hours | Notes |
|------|-------|-------|
| XS | ≤2h | trivial config / 1-file edit |
| S | 2-4h | localized change, 2-3 files |
| M | 1d | new module, schema migration |
| L | 2-3d | cross-cutting change |
| XL | >3d | SPLIT: never lock as single task |
  • scripts
    • render.py 8.6 KB 
      #!/usr/bin/env python3
"""Render a brief/proposal markdown artifact to its deliverable HTML page.

Status banner, side TOC, inverted-pyramid typography, mermaid rendered
client-side. The markdown is base64-embedded so accents, code fences and
</script> sequences survive intact.

Usage: render.py <artifact.md> [--no-open]
"""

import base64
import re
import sys
import subprocess
import tempfile
import time
from pathlib import Path

STATUS_TONES = {
    "accepted": "good", "ready": "good", "shipped": "good",
    "review": "warn", "draft": "neutral", "rejected": "bad",
}

TEMPLATE = """<!doctype html>
<html lang="fr">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>__TITLE__</title>
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Newsreader:ital,opsz,wght@0,6..72,400;0,6..72,600;1,6..72,400&family=IBM+Plex+Mono:wght@400;500&family=IBM+Plex+Sans:wght@400;500;600&display=swap">
<script src="https://cdn.jsdelivr.net/npm/marked@12/marked.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.min.js"></script>
<style>
:root {
  --ground:#f6f6f4; --sheet:#fff; --sunk:#ededea; --ink:#17191d;
  --ink-soft:#52565c; --ink-faint:#8b8f96; --rule:#dddcd7;
  --accent:#1f4d7a; --good:#34613f; --good-bg:#e4ede6;
  --warn:#8a5a2b; --warn-bg:#f3ead9; --bad:#a33a3a; --bad-bg:#f3e0e0;
  --neutral:#52565c; --neutral-bg:#ededea;
}
@media (prefers-color-scheme: dark) {
  :root {
    --ground:#121316; --sheet:#1a1c20; --sunk:#212429; --ink:#e9e9e7;
    --ink-soft:#a6aab0; --ink-faint:#70747b; --rule:#2d3137;
    --accent:#7fb0da; --good:#8cbd9a; --good-bg:#1c2b21;
    --warn:#cb9c64; --warn-bg:#2e2517; --bad:#d98080; --bad-bg:#2e1a1a;
    --neutral:#a6aab0; --neutral-bg:#212429;
  }
}
* { box-sizing:border-box; }
body { margin:0; background:var(--ground); color:var(--ink);
  font:16px/1.65 "IBM Plex Sans",system-ui,sans-serif;
  -webkit-font-smoothing:antialiased; }
.grid { max-width:72rem; margin:0 auto; padding:2.5rem 1.5rem 6rem;
  display:grid; grid-template-columns:14rem minmax(0,1fr); gap:3rem;
  align-items:start; }
@media (max-width:54rem) { .grid { grid-template-columns:minmax(0,1fr); }
  #toc { display:none; } }
#toc { position:sticky; top:1.5rem; font-size:.82rem;
  display:flex; flex-direction:column; gap:.15rem; }
#toc .t { font:.66rem/1 "IBM Plex Mono",monospace; letter-spacing:.12em;
  text-transform:uppercase; color:var(--ink-faint); margin-bottom:.5rem; }
#toc a { color:var(--ink-soft); text-decoration:none; padding:.22rem .6rem;
  border-left:2px solid var(--rule); line-height:1.35; }
#toc a:hover { color:var(--ink); }
#toc a.here { color:var(--accent); border-left-color:var(--accent); }
.statusbar { display:flex; flex-wrap:wrap; gap:.5rem 1.6rem;
  align-items:center; padding:.75rem 1.1rem; background:var(--sheet);
  border:1px solid var(--rule); margin-bottom:2.2rem;
  font:.76rem/1.4 "IBM Plex Mono",monospace; color:var(--ink-soft); }
.pill { font-weight:500; padding:.14rem .6rem; }
.pill.good { background:var(--good-bg); color:var(--good); }
.pill.warn { background:var(--warn-bg); color:var(--warn); }
.pill.bad { background:var(--bad-bg); color:var(--bad); }
.pill.neutral { background:var(--neutral-bg); color:var(--neutral); }
#doc { min-width:0; }
#doc h1 { font:600 clamp(1.8rem,4vw,2.5rem)/1.15 Newsreader,Georgia,serif;
  letter-spacing:-.015em; margin:0 0 1.4rem; text-wrap:balance; }
#doc h2 { font:600 1.45rem/1.25 Newsreader,Georgia,serif;
  margin:3rem 0 .9rem; padding-top:1.6rem; border-top:1px solid var(--rule);
  letter-spacing:-.01em; }
#doc h3 { font-size:.98rem; font-weight:600; margin:1.8rem 0 .5rem; }
#doc p, #doc li { max-width:65ch; }
#doc p { margin:0 0 .9rem; }
#doc ul, #doc ol { padding-left:1.2rem; }
#doc li { margin-bottom:.35rem; }
#doc li::marker { color:var(--ink-faint); }
#doc a { color:var(--accent); }
#doc code { font:.85em "IBM Plex Mono",monospace; background:var(--sunk);
  padding:.08em .35em; }
#doc pre { background:var(--sheet); border:1px solid var(--rule);
  padding:1.1rem 1.3rem; overflow-x:auto; }
#doc pre code { background:none; padding:0; font-size:.82rem; }
#doc blockquote { margin:1.2rem 0; padding:1rem 1.4rem;
  background:var(--good-bg); border-left:3px solid var(--good); }
#doc blockquote p { font:1.05rem/1.5 Newsreader,Georgia,serif; margin:0; }
.tw { overflow-x:auto; margin:.8rem 0 1.4rem; }
#doc table { width:100%; border-collapse:collapse; font-size:.86rem;
  background:var(--sheet); border:1px solid var(--rule); }
#doc th { text-align:left; font-size:.72rem; letter-spacing:.06em;
  text-transform:uppercase; color:var(--ink-faint);
  padding:.55rem .9rem; border-bottom:1px solid var(--rule);
  white-space:nowrap; }
#doc td { padding:.55rem .9rem; border-bottom:1px solid var(--rule);
  vertical-align:top; color:var(--ink-soft); }
#doc td:first-child { color:var(--ink); }
#doc tr:last-child td { border-bottom:none; }
.mermaid { background:var(--sheet); border:1px solid var(--rule);
  padding:1.2rem; margin:.8rem 0 1.4rem; overflow-x:auto;
  display:flex; justify-content:center; }
</style>
</head>
<body>
<div class="grid">
  <nav id="toc"><div class="t">Sommaire</div></nav>
  <article id="doc">
    <div class="statusbar">__BANNER__</div>
    <div id="content"></div>
  </article>
</div>
<script>
const raw = decodeURIComponent(escape(atob("__B64__")));
marked.use({ mangle:false, headerIds:false });
const dark = matchMedia("(prefers-color-scheme: dark)").matches;
mermaid.initialize({ startOnLoad:false, theme: dark ? "dark" : "neutral" });

const content = document.getElementById("content");
content.innerHTML = marked.parse(raw);

content.querySelectorAll("code.language-mermaid").forEach((c) => {
  const d = document.createElement("div");
  d.className = "mermaid";
  d.textContent = c.textContent;
  c.closest("pre").replaceWith(d);
});
mermaid.run({ querySelector: ".mermaid" });

content.querySelectorAll("table").forEach((t) => {
  const w = document.createElement("div");
  w.className = "tw";
  t.replaceWith(w);
  w.appendChild(t);
});

const toc = document.getElementById("toc");
const heads = [...content.querySelectorAll("h2")];
heads.forEach((h, i) => {
  h.id = "s" + i;
  const a = document.createElement("a");
  a.href = "#s" + i;
  a.textContent = h.textContent.replace(/^[0-9]+[.]\\s*/, "");
  toc.appendChild(a);
});
const links = [...toc.querySelectorAll("a")];
const obs = new IntersectionObserver((es) => {
  es.forEach((e) => {
    if (!e.isIntersecting) return;
    links.forEach((a) =>
      a.classList.toggle("here", a.getAttribute("href") === "#" + e.target.id));
  });
}, { rootMargin: "-15% 0px -75% 0px" });
heads.forEach((h) => obs.observe(h));
</script>
</body>
</html>
"""


def parse_frontmatter(text):
    if not text.startswith("---"):
        return {}, text
    end = text.find("\n---", 3)
    if end == -1:
        return {}, text
    meta = {}
    for line in text[3:end].splitlines():
        m = re.match(r"^(\w+):\s*(.+?)\s*$", line)
        if m:
            meta[m.group(1)] = m.group(2).strip("\"'")
    return meta, text[end + 4:].lstrip("\n")


def banner(meta):
    status = meta.get("status", "Draft")
    tone = STATUS_TONES.get(status.lower(), "neutral")
    parts = ['<span class="pill %s">%s</span>' % (tone, status)]
    ident = meta.get("proposal_id") or meta.get("rfc_id") or meta.get("brief_id")
    if ident and meta.get("slug"):
        parts.append("<span>%s · %s</span>" % (ident, meta["slug"]))
    elif ident:
        parts.append("<span>%s</span>" % ident)
    if meta.get("format"):
        parts.append("<span>format %s</span>" % meta["format"])
    if meta.get("updated") or meta.get("created"):
        parts.append("<span>%s</span>" % (meta.get("updated") or meta.get("created")))
    if meta.get("author"):
        parts.append("<span>%s</span>" % meta["author"])
    return "\n".join(parts)


def main():
    args = [a for a in sys.argv[1:] if not a.startswith("--")]
    if not args:
        sys.exit("usage: render.py <artifact.md> [--no-open]")
    src = Path(args[0])
    text = src.read_text(encoding="utf-8")
    meta, body = parse_frontmatter(text)

    m = re.search(r"^#\s+(.+)$", body, re.M)
    title = meta.get("title") or (m.group(1) if m else src.stem)
    page = (
        TEMPLATE
        .replace("__TITLE__", title)
        .replace("__BANNER__", banner(meta))
        .replace("__B64__", base64.b64encode(body.encode("utf-8")).decode("ascii"))
    )

    out = Path(tempfile.gettempdir()) / ("%s-%d.html" % (src.stem.lower(), int(time.time())))
    out.write_text(page, encoding="utf-8")
    print(out)
    if "--no-open" not in sys.argv:
        subprocess.run(["open", str(out)], check=False)


if __name__ == "__main__":
    main()
  • steps
    • step-00-init.md 410 B 
      # step 00 init

Resolve the requested output and any existing proposal. Pick the smallest sufficient format from the question; preserve stable section numbers. Start Draft. No format/start ceremony.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-01-context.md 421 B 
      # step 01 context

Read the relevant source and prior decisions only. Use existing code intelligence when useful. Search external sources only for unresolved external claims. Do not create context for padding.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-02-problem.md 407 B 
      # step 02 problem

State the observed problem, desired result and non-goals from supplied evidence. Ask only about a missing decision that changes the design. Do not repeat a completed interview.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-03-alternatives.md 398 B 
      # step 03 alternatives

Compare genuine alternatives and status quo where useful. Never add an option to meet a count. State concrete tradeoffs and what evidence would change the choice.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-04-design.md 421 B 
      # step 04 design

Describe the chosen interfaces, state transitions and relevant failure handling. Include a diagram only when it communicates real structure. Do not implement or invent unrelated abstractions.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-05-risks.md 403 B 
      # step 05 risks

List substantiated risks, mitigations and actual unknowns. Distinguish observed failure from inference. Do not invent a risk quota or require a new test layer for every task.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-06-recommendation.md 434 B 
      # step 06 recommendation

Recommend the smallest sufficient approach and explain why the real alternatives lose. State uncertainty and cite supporting evidence. No extra research after the decision is adequately supported.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-07-impl-plan.md 429 B 
      # step 07 impl plan

Write dependency-ordered implementation outcomes and proportionate verification. No arbitrary one-day, test-layer or parallelism quotas. Account for shared build resources as well as file overlap.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-08-review.md 461 B 
      # step 08 review

The lead reviews the completed draft. An independent reviewer requires explicit user consent, including under auto mode. If approved, give one bounded risk question and collect its supported findings once. Empty findings are valid.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
    • step-09-finalize.md 501 B 
      # step 09 finalize

Leave Draft/Review until explicit user acceptance; never default to Accepted. After acceptance, preserve source-brief links and normal handoff without launching implementation. Render only when requested. Do not automatically open a browser or update unrelated indexes.

The current SKILL.md owns the workflow policy. User consent is required
before any agent, reviewer or advisor. No automatic validation sessions
for prose; no continuation after a user stop or completed result.
  • SKILL.md 2.2 KB 
    ---
name: propose
description: Design a concrete technical proposal with evidence and tradeoffs when a decision needs design. No implementation or automatic reviewer.
argument-hint: "<question> [--short|--full] [--auto] [--scope path] [--no-review] [--out dir] [--html]"
---

# Propose

Gather only the context needed to answer the design question. Prefer the
smallest sufficient format: short for a bounded reversible choice, standard
for one system, full for a genuine cross-system design. No format interview
when the request already determines the appropriate size.

Use references/proposal-template.md for stable section numbers and artifact
shape. Write problem, real alternatives (including status quo when relevant),
tradeoffs, design, risks, recommendation and runnable implementation tasks.
Do not manufacture alternatives, diagrams, metrics or verification layers
to fill a template. Ask only about a blocking decision not recoverable from
code or the request. Research only unresolved external questions.

Review the draft yourself. An independent review is optional and requires
explicit user consent, never merely omission of --no-review. Retain supported
findings only. Leave status Draft or Review until the user explicitly accepts
the proposal; writing it is not implementation approval.

Keep the existing docs/proposals/<id>-<slug>/PROPOSAL.md layout and links to
a source brief. Do not supersede that brief until the design is accepted.
Render via scripts/render.py only on --html or request. Do not launch ship,
open a browser, create an index, or start another agent just to finish.

## Arsenal handoff

When called by Arsenal, return the proposal, status and unresolved decisions
to Arsenal. Do not launch ship yourself. Explicit user acceptance remains
required before Arsenal can consume the proposal for implementation, even
when the original request was to build the feature.

## Execution policy

Work solo. Ask before any subagent or reviewer, even in auto mode. Explain
the independent scope and expected benefit first. No hidden advisor, nested
delegation, model retuning, repeated successful checks, or progress spam.
Use existing context before asking questions. Stop when the requested result
is delivered. User stops and scope changes override pending steps.

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related

Claude Prompt
Tighten-my-prose editing prompt
Claude Skill
Adversarial code-review skill for Claude
Claude Workflow
Deep-research workflow (fan-out + verify)
Claude Skill
Conventional-commit writer for Claude