propose

Name: propose
Author: Codagent-AI

28stars1forks

How to install propose?

codagent-ai/agent-skills/propose

$npx -y skills add Codagent-AI/agent-skills --skill propose

Installs into the current project.

Summary

Evaluate whether a software idea is worth building, then write the proposal document. Use when the user wants to assess an idea, says "evaluate", "propose", "is this worth building", or "should we build". If the idea passes evaluation, write the proposal document using the provid

Files · 1

View on GitHub

SKILL.md

1	# Propose
2
3	Evaluate whether an idea is worth formalizing, and if so, write the proposal document. This sits between optional freeform exploration and the formal design artifact.
4
5	The proposal is a "why + high-level what + high-level how" document. Deeply understand and articulate the motivation — the problem, the opportunity, and why it matters now. Scope "what" at a high level — enough to bound the change and identify capabilities, but leave detailed behavioral requirements for specs. Sketch the high-level technical approach and architecture — enough to ground the change in reality and surface structural risks early — but leave detailed design for design.md.
6
7	## Principles
8
9	- Conversational evaluation, documentary proposal — The evaluation phase is a conversation. The proposal phase produces `proposal.md`. Keep these phases distinct.
10	- Research-informed — Before opining, investigate the codebase and web resources to ground advice in reality.
11	- Honest assessment — If an idea has problems, say so directly. "Not worth building" is a valid and valuable outcome. A brainstorm that only cheerleads is useless.
12	- Visual — Use ASCII diagrams liberally when they'd help clarify thinking: architecture maps, comparison tables, flow sketches.
13	- Why-first, then lightly — The proposal establishes motivation first, then scopes the change at a high level, then sketches the high-level technical approach. Dig into the problem deeply. Scope "what" enough to bound capabilities and identify what needs specs — but leave detailed behavioral requirements for specs. Capture enough architecture and key technical decisions to ground the proposal in reality — but leave detailed design, component internals, and implementation specifics for design.md.
14
15	## Flow
16
17	### 1. Understand
18
19	First understand the idea. If the user's invocation didn't include enough context, follow the `codagent:ask-questions` skill to gather:
20	- What is the idea? What does it do from the user's perspective?
21	- What problem does it solve? Who has this problem?
22	- What triggered this? (bug report, user request, personal itch, competitive pressure)
23	- What would make this successful? What is explicitly out of scope?
24
25	Focus on purpose, constraints, success criteria, audience, and scope boundaries. Do not proceed until you have a concrete understanding of the idea. If the prompt is rough, ask specific discovery questions before evaluating or drafting — do not jump straight to a proposal-shaped artifact.
26
27	### 2. Research
28
29	Investigate before forming opinions. Do this proactively.
30
31	Spec research (when requirement specs exist):
32	- Review existing specs to understand current system behavior
33	- Identify if the idea conflicts with or extends existing capabilities
34
35	Codebase research (when a relevant codebase exists):
36	- Explore existing architecture to understand how this idea would fit
37	- Look for existing patterns, infrastructure, or prior attempts
38	- Identify areas that would be affected
39
40	Web research (when applicable):
41	- How others have solved similar problems
42	- Existing libraries, tools, or services that could help
43	- Known pitfalls or anti-patterns
44
45	When sharing findings, use diagrams to show architecture fits, data flows, or option comparisons rather than just prose.
46
47	### 3. Evaluate Worth
48
49	This is the decision point. Before going further into "how", assess whether this is worth doing:
50
51	- Problem significance — Is the problem real and meaningful? How many users/systems are affected?
52	- Alternatives to building — Could the goal be achieved with configuration, an existing tool, or a third-party service?
53	- Opportunity cost — What else could be built with the same effort? Is this the highest-value use of time?
54	- Maintenance burden — What ongoing cost does this introduce?
55
56	Be direct about the verdict:
57
58	```text
59	VERDICT
60	════════════════════════════════════════════
61
62	GO Worth pursuing.
63	→ Explore the approach, then write the proposal
64
65	GO WITH Worth pursuing, but with
66	CAVEATS scope or approach adjustments.
67	→ Discuss adjustments first
68
69	NO-GO Not worth building.
70	→ State why directly.
71	```
72
73	A "no-go" requires explanation: what specifically makes this not worth pursuing, and whether anything could change that assessment. If the user disagrees, engage with their reasoning — but ultimately it's their decision.
74
75	### 4. Explore the Approach (lightly)
76
77	Only reached on GO or GO WITH CAVEATS. Sketch the high-level technical approach — enough to ground the proposal in architectural reality and surface structural risks. This is NOT the design phase; you're

People who liked this also viewed

6 picks

Type

propose

28stars1forks

View on GitHub

How to install propose?

codagent-ai/agent-skills/propose

$npx -y skills add Codagent-AI/agent-skills --skill propose

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Propose
2
3	Evaluate whether an idea is worth formalizing, and if so, write the proposal document. This sits between optional freeform exploration and the formal design artifact.
4
5	The proposal is a "why + high-level what + high-level how" document. Deeply understand and articulate the motivation — the problem, the opportunity, and why it matters now. Scope "what" at a high level — enough to bound the change and identify capabilities, but leave detailed behavioral requirements for specs. Sketch the high-level technical approach and architecture — enough to ground the change in reality and surface structural risks early — but leave detailed design for design.md.
6
7	## Principles
8
9	- Conversational evaluation, documentary proposal — The evaluation phase is a conversation. The proposal phase produces `proposal.md`. Keep these phases distinct.
10	- Research-informed — Before opining, investigate the codebase and web resources to ground advice in reality.
11	- Honest assessment — If an idea has problems, say so directly. "Not worth building" is a valid and valuable outcome. A brainstorm that only cheerleads is useless.
12	- Visual — Use ASCII diagrams liberally when they'd help clarify thinking: architecture maps, comparison tables, flow sketches.
13	- Why-first, then lightly — The proposal establishes motivation first, then scopes the change at a high level, then sketches the high-level technical approach. Dig into the problem deeply. Scope "what" enough to bound capabilities and identify what needs specs — but leave detailed behavioral requirements for specs. Capture enough architecture and key technical decisions to ground the proposal in reality — but leave detailed design, component internals, and implementation specifics for design.md.
14
15	## Flow
16
17	### 1. Understand
18
19	First understand the idea. If the user's invocation didn't include enough context, follow the `codagent:ask-questions` skill to gather:
20	- What is the idea? What does it do from the user's perspective?
21	- What problem does it solve? Who has this problem?
22	- What triggered this? (bug report, user request, personal itch, competitive pressure)
23	- What would make this successful? What is explicitly out of scope?
24
25	Focus on purpose, constraints, success criteria, audience, and scope boundaries. Do not proceed until you have a concrete understanding of the idea. If the prompt is rough, ask specific discovery questions before evaluating or drafting — do not jump straight to a proposal-shaped artifact.
26
27	### 2. Research
28
29	Investigate before forming opinions. Do this proactively.
30
31	Spec research (when requirement specs exist):
32	- Review existing specs to understand current system behavior
33	- Identify if the idea conflicts with or extends existing capabilities
34
35	Codebase research (when a relevant codebase exists):
36	- Explore existing architecture to understand how this idea would fit
37	- Look for existing patterns, infrastructure, or prior attempts
38	- Identify areas that would be affected
39
40	Web research (when applicable):
41	- How others have solved similar problems
42	- Existing libraries, tools, or services that could help
43	- Known pitfalls or anti-patterns
44
45	When sharing findings, use diagrams to show architecture fits, data flows, or option comparisons rather than just prose.
46
47	### 3. Evaluate Worth
48
49	This is the decision point. Before going further into "how", assess whether this is worth doing:
50
51	- Problem significance — Is the problem real and meaningful? How many users/systems are affected?
52	- Alternatives to building — Could the goal be achieved with configuration, an existing tool, or a third-party service?
53	- Opportunity cost — What else could be built with the same effort? Is this the highest-value use of time?
54	- Maintenance burden — What ongoing cost does this introduce?
55
56	Be direct about the verdict:
57
58	```text
59	VERDICT
60	════════════════════════════════════════════
61
62	GO Worth pursuing.
63	→ Explore the approach, then write the proposal
64
65	GO WITH Worth pursuing, but with
66	CAVEATS scope or approach adjustments.
67	→ Discuss adjustments first
68
69	NO-GO Not worth building.
70	→ State why directly.
71	```
72
73	A "no-go" requires explanation: what specifically makes this not worth pursuing, and whether anything could change that assessment. If the user disagrees, engage with their reasoning — but ultimately it's their decision.
74
75	### 4. Explore the Approach (lightly)
76
77	Only reached on GO or GO WITH CAVEATS. Sketch the high-level technical approach — enough to ground the proposal in architectural reality and surface structural risks. This is NOT the design phase; you're

People who liked this also viewed

6 picks

Type