Skip to content
cccskills
FreePublished on GitHub

propose

Design a concrete technical proposal with evidence and tradeoffs when a decision needs design. No implementation or automatic reviewer.

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

See how to install

Files included (14)

  • SKILL.md3.1 KB
  • references/interview-questions.md4.0 KB
  • references/proposal-template.md6.0 KB
  • scripts/render.py8.6 KB
  • steps/step-00-init.md410 B
  • steps/step-01-context.md421 B
  • steps/step-02-problem.md432 B
  • steps/step-03-alternatives.md462 B
  • steps/step-04-design.md485 B
  • steps/step-05-risks.md403 B
  • steps/step-06-recommendation.md434 B
  • steps/step-07-impl-plan.md429 B
  • steps/step-08-review.md461 B
  • steps/step-09-finalize.md857 B

SKILL.md (original)

Review the instructions the agent will receive before you install.

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. Research only unresolved external questions.

Interview

Without --auto, interview the user before drafting: problem, scope, goals/non-goals, alternatives direction, design choices. One question per message, in plain text, then wait for the answer. Draw questions from references/interview-questions.md; skip one only when the request already answers it. Never infer an answer the user can give. Under --auto, infer from code and the request and ask only about a blocking decision.

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. On acceptance, record the Git base and branch in the frontmatter (steps/step-09-finalize.md) so ship branches without asking again. 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.

Verify external facts

Before stating an external fact (a version, an API, a price, a date, a regulation, the behaviour of a tool or library, a person or company), search first when the runtime offers web search: read the websearch skill and run one quick search, then cite the source. One search per fact; --deep only on request. Without web search, mark the claim unverified. Facts visible in the repository or the request need no search.

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. Stop when the requested result is delivered. User stops and scope changes override pending steps.

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

Use when the user invokes Arsenal, needs help choosing an approach, or wants an end-to-end task handled with the installed Arsenal skills.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

brief

Free

Write a product brief and its task list when the user requests a product specification. Never implement it.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

issue

Free

Create, update or resume a GitHub or Linear issue as durable resolution memory when requested.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

next

Free

Start a session from what was left - trace saves, briefs, proposals, review reports, issues - and ask what to continue. Never resume or implement automatically.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

review

Free

Deep code review driven by a short interview. Read-only reader agents analyze the chosen scope per angle, the lead verifies every finding, and each point is routed to the skill that fixes it. Never edits the code.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

ship

Free

Implement a clear request or an approved brief/proposal. Work solo, make the smallest sufficient change, verify the changed behavior, and stop. Ask before any delegation.

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

mirkobozzetto/arsenal21Updated Oct 19, 2026

See all skills by mirkobozzetto

Report a problem with this skill