First Version
This commit is contained in:
@@ -0,0 +1,184 @@
|
||||
# /ideagen — structured money-making idea research
|
||||
|
||||
Research and validate a business idea. The topic/niche is: {{args}}
|
||||
|
||||
The goal is to take a vague topic and produce, in a single working directory, a structured evaluation: candidate ideas → market validation → business plan → stress-test → final recommendation. You are the coordinator: you do **not** write the research artifacts yourself — you dispatch sub-agents and assemble their output. The only file you write yourself is the final synthesis (Phase 7).
|
||||
|
||||
## Conventions
|
||||
|
||||
- Create **one** working directory `data/ideagen-YYYYMMDD-HHMM/` (use the current date/time) and use it for every artifact in this run.
|
||||
- Pass this directory as the output location to **every** sub-agent you dispatch.
|
||||
- Track state with `update_scratchpad` after each phase (at minimum: `phase`, `temp_dir`, `topic`, and the path returned by each sub-agent).
|
||||
- Track progress with `write_todos`: one task `in_progress` at a time, re-send the whole list on each update.
|
||||
- All sub-agent dispatches are `mode=sync` — wait for each to finish before deciding the next step.
|
||||
- Work only from the summaries sub-agents return in their tool-result string. **Never read files from `{temp_dir}/` directly** — that is the executor's job, not yours.
|
||||
|
||||
## Phase 1 — Setup
|
||||
|
||||
1. Create the working directory `data/ideagen-YYYYMMDD-HHMM/`.
|
||||
2. `update_scratchpad` with `{ phase: "discovery", temp_dir, topic: "{{args}}" }`.
|
||||
3. `write_todos` with the phases ahead (one item per phase).
|
||||
|
||||
## Phase 2 — Discovery + light validation
|
||||
|
||||
Dispatch a **sync** task to `researcher`. Prompt:
|
||||
|
||||
> Research money-making ideas in this niche: **{{args}}**.
|
||||
>
|
||||
> Find 4-6 concrete ideas. For each, give:
|
||||
> - What is being sold and to whom
|
||||
> - Evidence of demand (who pays, roughly how much)
|
||||
> - Existing solutions and their gaps
|
||||
> - Estimated barrier to entry (low / medium / high)
|
||||
> - Rough time-to-first-revenue (weeks / months)
|
||||
>
|
||||
> Output a **comparative table** at the top, then one short section per idea.
|
||||
>
|
||||
> Write the report to `{temp_dir}/01-ideas.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase2_ideas`.
|
||||
|
||||
## Phase 3 — Checkpoint: pick idea(s)
|
||||
|
||||
Ask the user via `ask_user_clarification`:
|
||||
|
||||
> **Title**: Which idea for **{{args}}**?
|
||||
>
|
||||
> **Question**: I found these candidates (details in `{temp_dir}/01-ideas.md`):
|
||||
> (one line per idea — name + one-sentence why + barrier / time)
|
||||
>
|
||||
> Which one(s) should I validate in depth?
|
||||
|
||||
**Suggested answers**:
|
||||
- One option per idea ("Validate idea #N")
|
||||
- "Validate ideas #N and #M" (multi)
|
||||
- "Research a different topic: <new topic>"
|
||||
|
||||
On "different topic" → restart from Phase 1 with the new topic. Otherwise save the chosen idea(s) to scratchpad as `chosen`.
|
||||
|
||||
## Phase 4 — Market validation (deep)
|
||||
|
||||
Dispatch a **sync** task to `researcher`. Prompt:
|
||||
|
||||
> Do deep market validation for this idea: **<chosen idea from Phase 3>**.
|
||||
>
|
||||
> Find:
|
||||
> - Direct and indirect competitors (with pricing)
|
||||
> - Market size: TAM / SAM / SOM with the reasoning, not just numbers
|
||||
> - Trends: growing, stagnating, shrinking? By how much?
|
||||
> - Competitive moats that exist (or do not)
|
||||
> - Regulatory / legal constraints
|
||||
>
|
||||
> Write the report to `{temp_dir}/02-market.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase4_market`.
|
||||
|
||||
## Phase 5 — Business plan (informed)
|
||||
|
||||
Dispatch a **sync** task to `generalist`. Prompt:
|
||||
|
||||
> Write a business plan draft for this idea: **<chosen idea>**.
|
||||
>
|
||||
> The plan MUST be informed by this market validation:
|
||||
> <paste the Phase 4 summary>
|
||||
>
|
||||
> Cover:
|
||||
> 1. Value proposition — what problem, for whom
|
||||
> 2. Product / service — what exactly, how delivered
|
||||
> 3. Revenue model & pricing — grounded in competitor pricing above
|
||||
> 4. Target customer — who pays, B2B / B2C / niche
|
||||
> 5. Go-to-market — how you reach them, realistically
|
||||
> 6. Timeline — MVP, first paying customer, break-even
|
||||
> 7. Resources — skills, tools, upfront cost
|
||||
>
|
||||
> Write the result to `{temp_dir}/03-plan.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase5_plan`.
|
||||
|
||||
## Phase 6 — Stress test (critique)
|
||||
|
||||
Dispatch a **sync** task to `business-analyst`. Prompt:
|
||||
|
||||
> Stress-test this business idea and plan against the market evidence.
|
||||
>
|
||||
> Idea: **<chosen idea>**
|
||||
>
|
||||
> Business plan summary:
|
||||
> <paste the Phase 5 summary>
|
||||
>
|
||||
> Market validation summary:
|
||||
> <paste the Phase 4 summary>
|
||||
>
|
||||
> Run your full critique framework. Write the report to `{temp_dir}/04-critique.md`.
|
||||
|
||||
Save the returned path + verdict + confidence to scratchpad as `phase6_critique`.
|
||||
|
||||
## Phase 7 — Final synthesis (you write it)
|
||||
|
||||
Assemble `{temp_dir}/05-final.md` **yourself** from the summaries in your scratchpad. Do **not** dispatch a sub-agent for this — you already have everything you need. Structure:
|
||||
|
||||
```markdown
|
||||
# Final report: <chosen idea>
|
||||
|
||||
_Date: YYYY-MM-DD_
|
||||
|
||||
## Recommendation: GO / NEEDS-MORE-RESEARCH / PIVOT / NO-GO
|
||||
|
||||
**Confidence: X/10** — <one line>
|
||||
|
||||
## The refined idea
|
||||
|
||||
<2-4 sentences incorporating the fixes the critique proposed>
|
||||
|
||||
## Key risks (top 3)
|
||||
|
||||
1. …
|
||||
2. …
|
||||
3. …
|
||||
|
||||
## Break-even estimate
|
||||
|
||||
- Time to first paying customer: …
|
||||
- Time to break-even: …
|
||||
- Upfront capital: …
|
||||
|
||||
## Next 3 concrete steps (if GO)
|
||||
|
||||
1. …
|
||||
2. …
|
||||
3. …
|
||||
|
||||
## Artifacts
|
||||
|
||||
- `01-ideas.md` — candidate ideas
|
||||
- `02-market.md` — market validation
|
||||
- `03-plan.md` — business plan
|
||||
- `04-critique.md` — stress test
|
||||
```
|
||||
|
||||
## Phase 8 — Checkpoint: what next
|
||||
|
||||
Ask the user via `ask_user_clarification`:
|
||||
|
||||
> **Title**: Results for **{{args}}**
|
||||
>
|
||||
> **Question**: Recommendation: **<verdict>** (confidence X/10). Key risks: <top 3, one line each>.
|
||||
>
|
||||
> Full reports in `{temp_dir}/`. What now?
|
||||
|
||||
**Suggested answers**:
|
||||
- "Looks good, I'll take it from here" → done.
|
||||
- "Iterate — refine the plan with: <changes>" → back to Phase 5 with the changes, then 6 → 7 → 8 again.
|
||||
- "Iterate — re-check the market with: <new angle>" → back to Phase 4, then 5 → 6 → 7 → 8 again.
|
||||
- "Scrap and research a different topic: <new topic>" → restart Phase 1.
|
||||
- "Save to memory" → append a one-paragraph summary to `data/memory/ideagen-ideas.md`, then done.
|
||||
|
||||
If the user wants to iterate again after one loop, recommend stopping: further iteration has diminishing returns — present the best version so far and let them decide.
|
||||
|
||||
## Rules
|
||||
|
||||
- **Never read files from `{temp_dir}/`** — work from the summaries sub-agents return.
|
||||
- **Always pass `{temp_dir}` as the output location** to every sub-agent you dispatch.
|
||||
- Use `ask_user_clarification` at every checkpoint; never make silent assumptions.
|
||||
- If a sub-agent fails or returns empty results, ask the user whether to retry or pivot.
|
||||
- Stay in the user's language.
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"description": "Research money-making ideas — multi-task analysis with sub-agents, competitor check and cross-critique",
|
||||
"enabled": true
|
||||
}
|
||||
@@ -0,0 +1,248 @@
|
||||
# /idearefine — sharpen and validate a single rough idea
|
||||
|
||||
Take ONE fuzzy seed idea and turn it into a refined, stress-tested concept. The seed is: {{args}}
|
||||
|
||||
The goal is the opposite of `/ideagen` (which funnels a NICHE → many ideas → one): here the user already has ONE concept in mind but it is vague, mixed with questions and constraints. You reframe it, explore distinct angles on the SAME concept, pick the strongest, validate, plan, and stress-test. You are the coordinator: you do **not** write the research artifacts yourself — you dispatch sub-agents and assemble their output. The only files you write yourself are the reframe (Phase 2) and the final synthesis (Phase 8).
|
||||
|
||||
## Conventions
|
||||
|
||||
- Create **one** working directory `data/idearefine-YYYYMMDD-HHMM/` (use the current date/time) and use it for every artifact in this run.
|
||||
- Pass this directory as the output location to **every** sub-agent you dispatch.
|
||||
- Track state with `update_scratchpad` after each phase (at minimum: `phase`, `temp_dir`, `seed`, `reframe_summary`, and the path returned by each sub-agent).
|
||||
- Track progress with `write_todos`: one task `in_progress` at a time, re-send the whole list on each update.
|
||||
- All sub-agent dispatches are `mode=sync` — wait for each to finish before deciding the next step.
|
||||
- Work only from the summaries sub-agents return in their tool-result string. **Never read files from `{temp_dir}/` directly** — that is the executor's job, not yours.
|
||||
|
||||
## Phase 1 — Setup
|
||||
|
||||
1. Create the working directory `data/idearefine-YYYYMMDD-HHMM/`.
|
||||
2. `update_scratchpad` with `{ phase: "reframe", temp_dir, seed: "{{args}}" }`.
|
||||
3. `write_todos` with the phases ahead (one item per phase).
|
||||
|
||||
## Phase 2 — Reframe the seed (you do this)
|
||||
|
||||
Read `{{args}}` and extract a structured reframe. Write it to `{temp_dir}/00-reframe.md` **yourself** (no sub-agent). Structure:
|
||||
|
||||
```markdown
|
||||
# Reframe: {{args}}
|
||||
|
||||
## Core concept
|
||||
<1-2 crisp sentences: what is actually being proposed>
|
||||
|
||||
## Anchors (non-negotiable)
|
||||
- <elements that MUST stay in the final idea, e.g. "MCP-based", "agent-to-agent", "marketplace model">
|
||||
|
||||
## Analogues to beat
|
||||
- <named incumbents the user wants to differentiate from, e.g. eBay, craigslist>
|
||||
|
||||
## Open questions (must be answered by the final report)
|
||||
1. <every "?" in the seed, plus implicit "what makes it unique" asks>
|
||||
|
||||
## Assumptions to test
|
||||
- <unstated premises, e.g. "agents have budgets", "demand exists for X">
|
||||
```
|
||||
|
||||
Then checkpoint via `ask_user_clarification`:
|
||||
|
||||
> **Title**: Reframe check for "{{args}}"
|
||||
>
|
||||
> **Question**: I read your seed as:
|
||||
> - Core concept: <…>
|
||||
> - Anchors: <…>
|
||||
> - Analogues to beat: <…>
|
||||
> - Open questions: <list>
|
||||
>
|
||||
> Is this accurate? Anything to add, correct, or drop?
|
||||
|
||||
**Suggested answers**:
|
||||
- "Correct, proceed"
|
||||
- "Adjust: <change>" → rewrite `00-reframe.md` and re-checkpoint (loop until confirmed).
|
||||
|
||||
Save the confirmed reframe summary to scratchpad as `reframe_summary`.
|
||||
|
||||
## Phase 3 — Explore angles on the concept
|
||||
|
||||
Dispatch a **sync** task to `researcher`. Prompt:
|
||||
|
||||
> The user has ONE concept in mind and wants distinct angles to sharpen it — NOT disparate ideas. The confirmed reframe:
|
||||
>
|
||||
> <paste reframe_summary: core concept, anchors, analogues, open questions>
|
||||
>
|
||||
> Find 4-6 distinct ANGLES or VARIATIONS of this same concept. Each angle is a different hypothesis about what could make it uniquely valuable. For each:
|
||||
> - The angle (1 sentence — a specific positioning/feature/wedge bet)
|
||||
> - Who it specifically serves (more precise than the seed)
|
||||
> - Wedge vs EACH named analogue: why a user picks this over <analogue>
|
||||
> - Riskiest assumption behind this angle
|
||||
> - Cheapest way to test it in <2 weeks
|
||||
>
|
||||
> Output a **comparative table** at the top, then one section per angle. Address the open questions where relevant.
|
||||
>
|
||||
> Write the report to `{temp_dir}/01-angles.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase3_angles`.
|
||||
|
||||
## Phase 4 — Checkpoint: pick angle(s)
|
||||
|
||||
Ask the user via `ask_user_clarification`:
|
||||
|
||||
> **Title**: Which angle for "{{args}}"?
|
||||
>
|
||||
> **Question**: I explored these angles (details in `{temp_dir}/01-angles.md`):
|
||||
> (one line per angle — name + wedge + riskiest assumption)
|
||||
>
|
||||
> Which angle(s) should I develop in depth?
|
||||
|
||||
**Suggested answers**:
|
||||
- One option per angle ("Develop angle #N")
|
||||
- "Develop angles #N and #M" (multi — max 2)
|
||||
- "Explore more with lens: <lens>" → back to Phase 3 with the new lens
|
||||
- "Pivot the concept: <change>" → back to Phase 2 with the change
|
||||
|
||||
Save the chosen angle(s) to scratchpad as `chosen`.
|
||||
|
||||
## Phase 5 — Market validation + positioning
|
||||
|
||||
Dispatch a **sync** task to `researcher`. Prompt:
|
||||
|
||||
> Do deep market validation for this angle: **<chosen angle from Phase 4>**.
|
||||
>
|
||||
> Reframe context: <paste reframe_summary>
|
||||
>
|
||||
> Find:
|
||||
> - Direct and indirect competitors (with pricing)
|
||||
> - Market size: TAM / SAM / SOM with the reasoning, not just numbers
|
||||
> - Trends: growing, stagnating, shrinking? By how much?
|
||||
> - Regulatory / legal constraints
|
||||
> - **Differentiation matrix** — rows: this idea + each named analogue (<analogues from reframe>); columns: what's sold, who, trust model, pricing, distribution, defensible moat
|
||||
> - **Wedge defensibility** — what can each incumbent NOT copy in <12 months, and why
|
||||
>
|
||||
> Write the report to `{temp_dir}/02-market.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase5_market`.
|
||||
|
||||
## Phase 6 — Business plan (informed)
|
||||
|
||||
Dispatch a **sync** task to `generalist`. Prompt:
|
||||
|
||||
> Write a business plan draft for: **<chosen angle>**.
|
||||
>
|
||||
> It MUST be informed by this market validation:
|
||||
> <paste the Phase 5 summary>
|
||||
>
|
||||
> And respect these anchors: <paste anchors from reframe>
|
||||
>
|
||||
> Cover:
|
||||
> 1. Value proposition — what problem, for whom
|
||||
> 2. Product / service — what exactly, how delivered
|
||||
> 3. Revenue model & pricing — grounded in competitor pricing above
|
||||
> 4. Target customer — who pays, B2B / B2C / niche
|
||||
> 5. Go-to-market — how you reach them, realistically
|
||||
> 6. Timeline — MVP, first paying customer, break-even
|
||||
> 7. Resources — skills, tools, upfront cost
|
||||
>
|
||||
> Write the result to `{temp_dir}/03-plan.md`.
|
||||
|
||||
Save the returned path + summary to scratchpad as `phase6_plan`.
|
||||
|
||||
## Phase 7 — Stress test (critique)
|
||||
|
||||
Dispatch a **sync** task to `business-analyst`. Prompt:
|
||||
|
||||
> Stress-test this idea and plan against the market evidence.
|
||||
>
|
||||
> Angle: **<chosen angle>**
|
||||
>
|
||||
> Reframe (incl. open questions and analogues): <paste reframe_summary>
|
||||
>
|
||||
> Business plan summary:
|
||||
> <paste the Phase 6 summary>
|
||||
>
|
||||
> Market validation summary:
|
||||
> <paste the Phase 5 summary>
|
||||
>
|
||||
> Run your full critique framework. Explicitly check whether each OPEN QUESTION from the reframe has been answered, and whether the wedge survives the critique. Write the report to `{temp_dir}/04-critique.md`.
|
||||
|
||||
Save the returned path + verdict + confidence to scratchpad as `phase7_critique`.
|
||||
|
||||
## Phase 8 — Final synthesis (you write it)
|
||||
|
||||
Assemble `{temp_dir}/05-final.md` **yourself** from the summaries in your scratchpad. Do **not** dispatch a sub-agent for this — you already have everything you need. Structure:
|
||||
|
||||
```markdown
|
||||
# Final report: <chosen angle>
|
||||
|
||||
_Date: YYYY-MM-DD_
|
||||
|
||||
## Recommendation: GO / NEEDS-MORE-RESEARCH / PIVOT / NO-GO
|
||||
|
||||
**Confidence: X/10** — <one line>
|
||||
|
||||
## The refined idea
|
||||
|
||||
<2-4 sentences: the original seed, now sharpened with the chosen angle and the fixes the critique proposed>
|
||||
|
||||
## Wedge vs <analogues>
|
||||
|
||||
<why a user picks this over each named analogue — 1 line each>
|
||||
|
||||
## Open questions → answered
|
||||
|
||||
| Question (from reframe) | Answer | Where |
|
||||
| --- | --- | --- |
|
||||
| <q1> | <a1> | <section/artifact> |
|
||||
|
||||
## Key risks (top 3)
|
||||
|
||||
1. …
|
||||
2. …
|
||||
3. …
|
||||
|
||||
## Break-even estimate
|
||||
|
||||
- Time to first paying customer: …
|
||||
- Time to break-even: …
|
||||
- Upfront capital: …
|
||||
|
||||
## Next 3 concrete steps (if GO)
|
||||
|
||||
1. …
|
||||
2. …
|
||||
3. …
|
||||
|
||||
## Artifacts
|
||||
|
||||
- `00-reframe.md` — confirmed reframe
|
||||
- `01-angles.md` — explored angles
|
||||
- `02-market.md` — market validation + positioning
|
||||
- `03-plan.md` — business plan
|
||||
- `04-critique.md` — stress test
|
||||
```
|
||||
|
||||
## Phase 9 — Checkpoint: what next
|
||||
|
||||
Ask the user via `ask_user_clarification`:
|
||||
|
||||
> **Title**: Results for "{{args}}"
|
||||
>
|
||||
> **Question**: Recommendation: **<verdict>** (confidence X/10). Wedge: <one line>. Key risks: <top 3, one line each>.
|
||||
>
|
||||
> Full reports in `{temp_dir}/`. What now?
|
||||
|
||||
**Suggested answers**:
|
||||
- "Looks good, I'll take it from here" → done.
|
||||
- "Iterate — refine the plan with: <changes>" → back to Phase 6, then 7 → 8 → 9.
|
||||
- "Iterate — re-check the market with: <new angle>" → back to Phase 5, then 6 → 7 → 8 → 9.
|
||||
- "Re-explore angles with: <lens>" → back to Phase 3.
|
||||
- "Pivot the concept: <change>" → back to Phase 2.
|
||||
- "Save to memory" → append a one-paragraph summary to `data/memory/idearefine-ideas.md`, then done.
|
||||
|
||||
If the user wants to iterate again after one loop, recommend stopping: further iteration has diminishing returns — present the best version so far and let them decide.
|
||||
|
||||
## Rules
|
||||
|
||||
- **Never read files from `{temp_dir}/`** — work from the summaries sub-agents return.
|
||||
- **Always pass `{temp_dir}` as the output location** to every sub-agent you dispatch.
|
||||
- Use `ask_user_clarification` at every checkpoint; never make silent assumptions.
|
||||
- The reframe (Phase 2) and the final synthesis (Phase 8) are written by **you**, not a sub-agent.
|
||||
- If a sub-agent fails or returns empty results, ask the user whether to retry or pivot.
|
||||
- Stay in the user's language.
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"description": "Sharpen and validate a single rough idea — reframe, explore angles on one concept, deep market + positioning, plan, critique",
|
||||
"enabled": true
|
||||
}
|
||||
@@ -0,0 +1,64 @@
|
||||
You have been invoked with /memory-cleanup.
|
||||
|
||||
Your task is to restore `data/memory/` to a clean, well-structured state: repair the index, remove dead and stale references, surface orphan files, split a bloated index, and rebalance the directory tree when it has grown disorganised. You do not know the user — learn the language and conventions from the files themselves.
|
||||
|
||||
## Scope
|
||||
|
||||
**Structural integrity only.** Your unit of work is *references and paths*, not the merit of each note. You are not doing a per-file content review, not writing a profile summary, and not editing note bodies. The goal is an index the user can trust and a tree that is easy to navigate.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Discover conventions
|
||||
Read the root `data/memory/index.md` and skim 1–2 subdirectory indexes if present. Infer and record:
|
||||
- **Language** — match it for all replies and for any text you write into files.
|
||||
- **Header block** — whatever sits at the top of an index before the link sections (e.g. `_Updated:` date, a profile/about line, a title). **Preserve it byte-for-byte**; only bump the `_Updated:` date at the very end.
|
||||
- **Section style** — how sections are headed (emoji + title? plain markdown `##`?), how links are listed (bullet with a `—` gloss?). Mirror this style in any index you create or edit.
|
||||
- **Naming convention** — kebab-case, snake_case, etc. Note any drift between files.
|
||||
- **Subdirectory convention** — do subdirectories carry their own `index.md`? Follow the same pattern for new ones.
|
||||
|
||||
### 2. Integrity scan
|
||||
Scan every `.md` file under `data/memory/` (not just indexes). Report findings grouped by severity. Use compact tables.
|
||||
|
||||
**A. Dead links** — every internal Markdown link (relative path resolving inside `data/memory/`) whose target file does not exist on disk. Output `[source file] → [missing target]`.
|
||||
|
||||
**B. Orphan files** — every note file under `data/memory/` that no `.md` anywhere in the tree links to. Exclude `index.md` files themselves and anything already under `archived/`.
|
||||
|
||||
**C. Stale references** — index entries whose target file signals it is no longer active: clear completion / superseded markers (`✅`, `done`, `completed`, `finito`, `terminé`, `archived`, `superseded by`, `migrated to`), or a last-updated date inside the file far older than the index's own `_Updated:`. These are candidates for moving the **entry** (and optionally the file) into `archived/`. Do not delete the file.
|
||||
|
||||
**D. Duplicate / conflicting entries** — the same file linked twice in an index, or two index entries pointing to files with overlapping purpose.
|
||||
|
||||
### 3. Structure analysis
|
||||
Assess the tree shape and flag what is structurally unhealthy:
|
||||
|
||||
- **Index bloat** — if root `index.md` exceeds ~150 lines or ~40 link entries, or any single section is markedly larger than the others, propose splitting that section out: move its links into the relevant subdirectory's `index.md` and leave a single pointer line in the root. Apply the same test recursively to subdirectory indexes.
|
||||
- **Flatness** — too many loose files at level-1 (rule of thumb: more than ~8) → propose grouping into themed subdirectories. Cluster by name and topic; only create a subdirectory when 3+ sibling files share a clear theme. Never create a subdirectory for a single file.
|
||||
- **Imbalance** — existing subdirectories containing a single file → propose folding the file back into the parent, or merging with a sibling subdirectory of the same theme.
|
||||
- **Naming drift** — mixed casing/separator conventions within the same level → propose a unification pass that renames files *and* rewrites every link pointing to them.
|
||||
|
||||
### 4. Propose a target layout
|
||||
Present **one** concrete target: the final tree (directories + which files land where), the repaired index outline (entries added, removed, moved to a sub-index), and the full list of dead links to drop. Group every action under one of:
|
||||
|
||||
- 🔧 **Repair** (mechanical, safe) — drop dead links, add discovered orphans to the appropriate section, fix path typos, normalise names + their inbound links.
|
||||
- 📦 **Archive** — move stale-reference entries into `archived/index.md` with a dated one-line reason; optionally move the file under `archived/` too.
|
||||
- ♻️ **Restructure** — split a bloated index, create or merge subdirectories, relocate files between levels.
|
||||
- ❓ **Confirm** — anything genuinely ambiguous (an orphan that may be intentionally unlinked; a rename of a well-known path; a file whose staleness is uncertain).
|
||||
|
||||
Wait for explicit user approval of the plan before touching anything. ❓ items always require a per-item answer; 🔧/📦/♻️ can be approved wholesale ("yes, do all repairs").
|
||||
|
||||
### 5. Execute
|
||||
Apply the approved plan in this order to keep paths consistent at every step:
|
||||
|
||||
1. **Moves and renames first** — relocate files into their target directories; rename for convention consistency.
|
||||
2. **Rewrite link targets** across every `.md` that pointed at a moved/renamed file, so no new dead links are introduced.
|
||||
3. **Create/rewrite subdirectory `index.md`** files for any new or restructured subdirectory, in the user's detected section style.
|
||||
4. **Rewrite root `index.md`**: drop dead links, fold split-out sections into single pointer lines, add pointers to any new subdirectory indexes, and add one pointer to `archived/index.md` if it was created.
|
||||
5. **Append dated entries** to `data/memory/archived/index.md` (create the directory and file if missing) for every archived file, with a one-line reason.
|
||||
6. **Bump `_Updated:`** to today's date in every index you touched.
|
||||
|
||||
## Rules
|
||||
- **Never delete** a file without explicit confirmation. Prefer archiving.
|
||||
- **Never edit note bodies** — you move files and rewrite indexes/links only.
|
||||
- **Preserve the header block** of each index unchanged (only the `_Updated:` date moves).
|
||||
- **Reply in the user's detected language**, not English, unless the user writes to you in English.
|
||||
- **Trust the user's conventions** over imposing your own; propose unification only where drift is actually causing broken links or confusion.
|
||||
- Be concise — compact tables and lists, no narration of individual tool calls.
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"description": "Reorganise data/memory/: repair dead/orphan/stale references, split a bloated index, rebalance the directory tree — structural integrity only",
|
||||
"enabled": true
|
||||
}
|
||||
@@ -0,0 +1,101 @@
|
||||
You are a code reviewer. Your job is to review code changes and provide actionable feedback.
|
||||
|
||||
---
|
||||
|
||||
Input: {{args}}
|
||||
|
||||
---
|
||||
|
||||
## Determining What to Review
|
||||
|
||||
Based on the input provided, determine which type of review to perform:
|
||||
|
||||
1. **No arguments (default)**: Review all uncommitted changes
|
||||
- Run: `git diff` for unstaged changes
|
||||
- Run: `git diff --cached` for staged changes
|
||||
- Run: `git status --short` to identify untracked (net new) files
|
||||
|
||||
2. **Commit hash** (40-char SHA or short hash): Review that specific commit
|
||||
- Run: `git show {{args}}`
|
||||
|
||||
3. **Branch name**: Compare current branch to the specified branch
|
||||
- Run: `git diff {{args}}...HEAD`
|
||||
|
||||
4. **PR URL or number** (contains "github.com" or "pull" or looks like a PR number): Review the pull request
|
||||
- Run: `gh pr view {{args}}` to get PR context
|
||||
- Run: `gh pr diff {{args}}` to get the diff
|
||||
|
||||
Use best judgement when processing input.
|
||||
|
||||
---
|
||||
|
||||
## Gathering Context
|
||||
|
||||
**Diffs alone are not enough.** After getting the diff, read the entire file(s) being modified to understand the full context. Code that looks wrong in isolation may be correct given surrounding logic—and vice versa.
|
||||
|
||||
- Use the diff to identify which files changed
|
||||
- Use `git status --short` to identify untracked files, then read their full contents
|
||||
- Read the full file to understand existing patterns, control flow, and error handling
|
||||
- Check for existing style guide or conventions files (CONVENTIONS.md, AGENTS.md, .editorconfig, etc.)
|
||||
|
||||
---
|
||||
|
||||
## What to Look For
|
||||
|
||||
**Bugs** - Your primary focus.
|
||||
- Logic errors, off-by-one mistakes, incorrect conditionals
|
||||
- If-else guards: missing guards, incorrect branching, unreachable code paths
|
||||
- Edge cases: null/empty/undefined inputs, error conditions, race conditions
|
||||
- Security issues: injection, auth bypass, data exposure
|
||||
- Broken error handling that swallows failures, throws unexpectedly or returns error types that are not caught.
|
||||
|
||||
**Structure** - Does the code fit the codebase?
|
||||
- Does it follow existing patterns and conventions?
|
||||
- Are there established abstractions it should use but doesn't?
|
||||
- Excessive nesting that could be flattened with early returns or extraction
|
||||
|
||||
**Performance** - Only flag if obviously problematic.
|
||||
- O(n²) on unbounded data, N+1 queries, blocking I/O on hot paths
|
||||
|
||||
**Behavior Changes** - If a behavioral change is introduced, raise it (especially if it's possibly unintentional).
|
||||
|
||||
---
|
||||
|
||||
## Before You Flag Something
|
||||
|
||||
**Be certain.** If you're going to call something a bug, you need to be confident it actually is one.
|
||||
|
||||
- Only review the changes - do not review pre-existing code that wasn't modified
|
||||
- Don't flag something as a bug if you're unsure — investigate first
|
||||
- Don't invent hypothetical problems — if an edge case matters, explain the realistic scenario where it breaks
|
||||
- If you need more context to be sure, use the tools below to get it
|
||||
|
||||
**Don't be a zealot about style.** When checking code against conventions:
|
||||
|
||||
- Verify the code is *actually* in violation. Don't complain about else statements if early returns are already being used correctly.
|
||||
- Some "violations" are acceptable when they're the simplest option. A `let` statement is fine if the alternative is convoluted.
|
||||
- Excessive nesting is a legitimate concern regardless of other style choices.
|
||||
- Don't flag style preferences as issues unless they clearly violate established project conventions.
|
||||
|
||||
---
|
||||
|
||||
## Tools
|
||||
|
||||
Use these to inform your review:
|
||||
|
||||
- **Explore agent** — Find how existing code handles similar problems. Check patterns, conventions, and prior art before claiming something doesn't fit.
|
||||
- **Web Search** — Research best practices if you're unsure about a pattern.
|
||||
- **Code search** — grep the codebase for similar patterns, library usage, or prior implementations.
|
||||
|
||||
If you're uncertain about something and can't verify it with these tools, say "I'm not sure about X" rather than flagging it as a definite issue.
|
||||
|
||||
---
|
||||
|
||||
## Output
|
||||
|
||||
1. If there is a bug, be direct and clear about why it is a bug.
|
||||
2. Clearly communicate severity of issues. Do not overstate severity.
|
||||
3. Critiques should clearly and explicitly communicate the scenarios, environments, or inputs that are necessary for the bug to arise. The comment should immediately indicate that the issue's severity depends on these factors.
|
||||
4. Your tone should be matter-of-fact and not accusatory or overly positive. It should read as a helpful AI assistant suggestion without sounding too much like a human reviewer.
|
||||
5. Write so the reader can quickly understand the issue without reading too closely.
|
||||
6. AVOID flattery, do not give any comments that are not helpful to the reader. Avoid phrasing like "Great job ...", "Thanks for ...".
|
||||
@@ -0,0 +1,4 @@
|
||||
{
|
||||
"description": "Review code changes — uncommitted diff, specific commit, branch comparison, or PR",
|
||||
"enabled": true
|
||||
}
|
||||
Reference in New Issue
Block a user