potetos-for-everyone 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/plugins/marketplace.json +21 -0
- package/.claude-plugin/marketplace.json +32 -0
- package/.claude-plugin/plugin.json +36 -0
- package/.codex-plugin/plugin.json +13 -0
- package/.codex-plugin/prompts/architect.md +6 -0
- package/.codex-plugin/prompts/arena.md +6 -0
- package/.codex-plugin/prompts/automate-me.md +6 -0
- package/.codex-plugin/prompts/blast-radius.md +6 -0
- package/.codex-plugin/prompts/bro.md +6 -0
- package/.codex-plugin/prompts/create-verification-skill.md +6 -0
- package/.codex-plugin/prompts/figure-it-out.md +6 -0
- package/.codex-plugin/prompts/how.md +6 -0
- package/.codex-plugin/prompts/interrogate.md +6 -0
- package/.codex-plugin/prompts/maintain-verification-skill.md +6 -0
- package/.codex-plugin/prompts/make-bot-ui.md +6 -0
- package/.codex-plugin/prompts/no-comments.md +6 -0
- package/.codex-plugin/prompts/poteto-mode.md +6 -0
- package/.codex-plugin/prompts/recall.md +6 -0
- package/.codex-plugin/prompts/reflect.md +6 -0
- package/.codex-plugin/prompts/setup-pstack.md +6 -0
- package/.codex-plugin/prompts/show-me-your-work.md +6 -0
- package/.codex-plugin/prompts/swarm.md +6 -0
- package/.codex-plugin/prompts/tdd.md +6 -0
- package/.codex-plugin/prompts/teach.md +6 -0
- package/.codex-plugin/prompts/technical-writing.md +6 -0
- package/.codex-plugin/prompts/typescript-best-practices.md +6 -0
- package/.codex-plugin/prompts/unslop.md +6 -0
- package/.codex-plugin/prompts/why.md +6 -0
- package/AGENTS.md +11 -0
- package/LICENSE +22 -0
- package/NOTICE.md +17 -0
- package/PORTABILITY.md +29 -0
- package/README.md +483 -0
- package/UPSTREAM.json +9 -0
- package/UPSTREAM_INVENTORY.json +13 -0
- package/VERSION +1 -0
- package/adapters/README.md +9 -0
- package/adapters/registry.json +46 -0
- package/agents/comment-reviewer.md +3 -0
- package/agents/comment-sicko.md +31 -0
- package/agents/poteto-agent.md +14 -0
- package/assets/logo.png +0 -0
- package/automations/benny/FOR_AGENTS.md +5 -0
- package/automations/benny/README.md +10 -0
- package/automations/benny/skills/reproduce-and-fix-issues/SKILL.md +12 -0
- package/automations/benny/skills/triage-issue-reports/SKILL.md +11 -0
- package/automations/benny/templates/configuration.example.yaml +11 -0
- package/automations/benny/templates/reproduce-automation-prompt.md +1 -0
- package/automations/benny/templates/triage-automation-prompt.md +1 -0
- package/bin/potetos +547 -0
- package/docs/.nojekyll +0 -0
- package/docs/guide/01-setup.md +25 -0
- package/docs/guide/02-poteto-mode.md +11 -0
- package/docs/guide/03-understand.md +5 -0
- package/docs/guide/04-design.md +5 -0
- package/docs/guide/05-build-and-clean.md +5 -0
- package/docs/guide/06-verify-and-ship.md +5 -0
- package/docs/guide/07-overnight.md +5 -0
- package/docs/guide/08-principles.md +5 -0
- package/docs/guide/09-make-it-yours.md +5 -0
- package/docs/guide/10-recipes-and-pitfalls.md +8 -0
- package/docs/guide/README.md +16 -0
- package/docs/index.html +422 -0
- package/hooks/hooks.json +17 -0
- package/hooks/session-start-context.md +11 -0
- package/npm/core.mjs +318 -0
- package/npm/postinstall.mjs +22 -0
- package/npm/potetos.mjs +145 -0
- package/package.json +98 -0
- package/runtime/README.md +21 -0
- package/runtime/__init__.py +1 -0
- package/runtime/capabilities.json +36 -0
- package/runtime/config.example.json +17 -0
- package/runtime/runner.py +240 -0
- package/skills/architect/SKILL.md +14 -0
- package/skills/arena/SKILL.md +14 -0
- package/skills/automate-me/SKILL.md +11 -0
- package/skills/blast-radius/SKILL.md +11 -0
- package/skills/bro/SKILL.md +7 -0
- package/skills/create-verification-skill/SKILL.md +11 -0
- package/skills/figure-it-out/SKILL.md +13 -0
- package/skills/how/SKILL.md +14 -0
- package/skills/interrogate/SKILL.md +14 -0
- package/skills/maintain-verification-skill/SKILL.md +11 -0
- package/skills/make-bot-ui/SKILL.md +11 -0
- package/skills/no-comments/SKILL.md +11 -0
- package/skills/poteto-mode/SKILL.md +93 -0
- package/skills/poteto-mode/playbooks/authoring-a-skill.md +7 -0
- package/skills/poteto-mode/playbooks/autonomous-run.md +7 -0
- package/skills/poteto-mode/playbooks/autopilot-full.md +7 -0
- package/skills/poteto-mode/playbooks/autopilot-stack.md +7 -0
- package/skills/poteto-mode/playbooks/babysit.md +7 -0
- package/skills/poteto-mode/playbooks/bug-fix.md +8 -0
- package/skills/poteto-mode/playbooks/eval.md +7 -0
- package/skills/poteto-mode/playbooks/feature.md +8 -0
- package/skills/poteto-mode/playbooks/hillclimb.md +8 -0
- package/skills/poteto-mode/playbooks/investigation.md +7 -0
- package/skills/poteto-mode/playbooks/multi-phase-plan.md +7 -0
- package/skills/poteto-mode/playbooks/opening-a-pr.md +7 -0
- package/skills/poteto-mode/playbooks/orchestrate.md +8 -0
- package/skills/poteto-mode/playbooks/pause-safely.md +7 -0
- package/skills/poteto-mode/playbooks/perf-issue.md +8 -0
- package/skills/poteto-mode/playbooks/prototype.md +7 -0
- package/skills/poteto-mode/playbooks/refactoring.md +7 -0
- package/skills/poteto-mode/playbooks/runtime-forensics.md +7 -0
- package/skills/poteto-mode/playbooks/session-pickup.md +7 -0
- package/skills/poteto-mode/playbooks/shipping.md +7 -0
- package/skills/poteto-mode/playbooks/trace-forensics.md +7 -0
- package/skills/poteto-mode/playbooks/visual-parity.md +7 -0
- package/skills/poteto-mode/playbooks/worktree-cleanup.md +7 -0
- package/skills/principle-attack-the-premise/SKILL.md +20 -0
- package/skills/principle-boundary-discipline/SKILL.md +20 -0
- package/skills/principle-build-the-lever/SKILL.md +20 -0
- package/skills/principle-encode-lessons-in-structure/SKILL.md +20 -0
- package/skills/principle-exhaust-the-design-space/SKILL.md +20 -0
- package/skills/principle-experience-first/SKILL.md +20 -0
- package/skills/principle-fix-root-causes/SKILL.md +20 -0
- package/skills/principle-foundational-thinking/SKILL.md +20 -0
- package/skills/principle-guard-the-context-window/SKILL.md +20 -0
- package/skills/principle-laziness-protocol/SKILL.md +20 -0
- package/skills/principle-make-operations-idempotent/SKILL.md +20 -0
- package/skills/principle-migrate-callers-then-delete-legacy-apis/SKILL.md +20 -0
- package/skills/principle-minimize-reader-load/SKILL.md +20 -0
- package/skills/principle-model-the-domain/SKILL.md +20 -0
- package/skills/principle-never-block-on-the-human/SKILL.md +20 -0
- package/skills/principle-outcome-oriented-execution/SKILL.md +20 -0
- package/skills/principle-prove-it-works/SKILL.md +20 -0
- package/skills/principle-redesign-from-first-principles/SKILL.md +20 -0
- package/skills/principle-separate-before-serializing-shared-state/SKILL.md +20 -0
- package/skills/principle-sequence-verifiable-units/SKILL.md +20 -0
- package/skills/principle-subtract-before-you-add/SKILL.md +20 -0
- package/skills/principle-test-behavior-not-implementation/SKILL.md +20 -0
- package/skills/principle-type-system-discipline/SKILL.md +20 -0
- package/skills/recall/SKILL.md +13 -0
- package/skills/reflect/SKILL.md +11 -0
- package/skills/setup-pstack/SKILL.md +12 -0
- package/skills/show-me-your-work/SKILL.md +17 -0
- package/skills/swarm/SKILL.md +12 -0
- package/skills/tdd/SKILL.md +12 -0
- package/skills/teach/SKILL.md +11 -0
- package/skills/technical-writing/SKILL.md +12 -0
- package/skills/typescript-best-practices/SKILL.md +14 -0
- package/skills/unslop/SKILL.md +11 -0
- package/skills/why/SKILL.md +14 -0
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Prototype
|
|
2
|
+
|
|
3
|
+
1. Write the decision the prototype must settle and the observable result that would favor each option.
|
|
4
|
+
2. Build the cheapest faithful sketch. For a contested design, create 2-3 materially different variants rather than polishing one.
|
|
5
|
+
3. Run or inspect the variants on the real or closest meaningful surface.
|
|
6
|
+
4. Compare results against the decision criteria, including costs that would survive into production.
|
|
7
|
+
5. Choose or reject based on evidence. Delete or clearly quarantine throwaway code unless the user asks to keep it.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Refactoring
|
|
2
|
+
|
|
3
|
+
1. State the invariant behavior and capture a baseline test, output, or runtime observation that proves it.
|
|
4
|
+
2. Map every caller and boundary touched by the structural change.
|
|
5
|
+
3. Prefer deletion, inlining, or one direct shape change over compatibility layers.
|
|
6
|
+
4. Make the transformation in verifiable units. Migrate callers before deleting old internal APIs.
|
|
7
|
+
5. Re-run the same behavior proof and relevant broader checks. Treat any behavior drift as a bug, not a refactor.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Runtime forensics
|
|
2
|
+
|
|
3
|
+
1. Define the live symptom and the shortest observation window that captures it.
|
|
4
|
+
2. Instrument the real process or surface with the least invasive probes that distinguish competing causes.
|
|
5
|
+
3. Collect runtime evidence and align events on one timeline.
|
|
6
|
+
4. Narrow to a causal mechanism. Run one perturbation or counterfactual check when possible.
|
|
7
|
+
5. Deliver a diagnosis and confidence level. Do not silently turn the diagnostic task into a fix.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Session pickup
|
|
2
|
+
|
|
3
|
+
1. Recover state from durable evidence first: branch/diff, decision log, issue/PR state, test outputs, and then prior transcript if available.
|
|
4
|
+
2. Write what is known, what was merely claimed, and what remains unverified.
|
|
5
|
+
3. Independently re-run the smallest proof for the current head before trusting a prior done-summary.
|
|
6
|
+
4. Reconstruct the next verifiable unit and continue from repository reality rather than transcript intent.
|
|
7
|
+
5. Update the pickup/decision record so another session can repeat the handoff.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Verify and ship
|
|
2
|
+
|
|
3
|
+
1. Enumerate the exact PR/commit stack in dependency order and freeze the heads being judged.
|
|
4
|
+
2. Independently verify each merge-ready head against its acceptance criteria; CI status alone is insufficient.
|
|
5
|
+
3. Identify the longest contiguous verified run from the root. Do not arm descendants above an unverified change.
|
|
6
|
+
4. Merge or land bottom-up only through the verified run, using the host repository mechanism available.
|
|
7
|
+
5. After each landing step, confirm the next head/base state still matches what was verified. Report every landed revision and any stop condition.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Captured trace forensics
|
|
2
|
+
|
|
3
|
+
1. Validate the artifact type, capture environment, clock/timebase, and whether the trace is complete enough to answer the question.
|
|
4
|
+
2. Find the dominant intervals, stacks, allocations, waits, or event clusters relevant to the symptom.
|
|
5
|
+
3. Connect hot/cold evidence to source and runtime behavior without equating correlation with cause.
|
|
6
|
+
4. Compare against another trace or source-level prediction when available.
|
|
7
|
+
5. Deliver the diagnosis, supporting trace locations, uncertainty, and the next discriminating measurement if needed.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Visual parity
|
|
2
|
+
|
|
3
|
+
1. Lock viewport, fonts, data, theme, device scale, and animation state so comparisons are meaningful.
|
|
4
|
+
2. Capture the reference and current rendering from the same surface.
|
|
5
|
+
3. Compare geometry first, then typography, spacing, color, and effects. Use image/pixel/overlay metrics when available.
|
|
6
|
+
4. Change one causal styling/layout cluster at a time and recapture.
|
|
7
|
+
5. Finish only when the agreed tolerance is met across the required states. Report exact remaining deltas if the environment blocks pixel proof.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
# Worktree and local-state cleanup
|
|
2
|
+
|
|
3
|
+
1. Inventory worktrees, branches, dirty state, unpushed commits, active processes, and related simulator/cache usage before deletion.
|
|
4
|
+
2. Classify each item as active, merged, abandoned-with-proof, or unknown. Unknown is preserved.
|
|
5
|
+
3. Preview the exact deletion/prune set and verify no active process or branch depends on it.
|
|
6
|
+
4. Delete only proven-safe items using the narrowest command available.
|
|
7
|
+
5. Re-inventory disk/worktree state and report reclaimed space plus everything intentionally preserved.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-attack-the-premise
|
|
3
|
+
description: Inventory who actually owns or exhibits the imbalance, then challenge the shared premise before writing another patch. Use when two or more fixes that share one premise have failed the same gate.
|
|
4
|
+
---
|
|
5
|
+
# Attack the Premise
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When two or more fixes that share one premise have failed the same gate.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Inventory who actually owns or exhibits the imbalance, then challenge the shared premise before writing another patch.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-boundary-discipline
|
|
3
|
+
description: Validate and normalize at boundaries, trust internal invariants, and keep business logic free of adapter noise. Use when at parsing, framework, process, network, storage, or user-input boundaries.
|
|
4
|
+
---
|
|
5
|
+
# Boundary Discipline
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
At parsing, framework, process, network, storage, or user-input boundaries.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Validate and normalize at boundaries, trust internal invariants, and keep business logic free of adapter noise.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-build-the-lever
|
|
3
|
+
description: Prefer a script, codemod, generator, benchmark, or verifier that performs or proves the work repeatably over hand edits. Use when for repetitive, large, or verification-heavy work.
|
|
4
|
+
---
|
|
5
|
+
# Build the Lever
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
For repetitive, large, or verification-heavy work.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Prefer a script, codemod, generator, benchmark, or verifier that performs or proves the work repeatably over hand edits.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-encode-lessons-in-structure
|
|
3
|
+
description: Turn recurring guidance into a type, lint, test, metadata flag, generator, runtime check, or skill so the system carries the lesson. Use when when the same corrective instruction appears more than once.
|
|
4
|
+
---
|
|
5
|
+
# Encode Lessons in Structure
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When the same corrective instruction appears more than once.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Turn recurring guidance into a type, lint, test, metadata flag, generator, runtime check, or skill so the system carries the lesson.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-exhaust-the-design-space
|
|
3
|
+
description: Build a few materially different cheap prototypes and compare evidence before committing to one design. Use when for novel interactions or architecture with no strong precedent.
|
|
4
|
+
---
|
|
5
|
+
# Exhaust the Design Space
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
For novel interactions or architecture with no strong precedent.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Build a few materially different cheap prototypes and compare evidence before committing to one design.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-experience-first
|
|
3
|
+
description: Optimize for the end-user experience unless the cost violates an explicit constraint. Use when product, UX, API design, or feature-scope tradeoffs arise.
|
|
4
|
+
---
|
|
5
|
+
# Experience First
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When product, UX, API design, or feature-scope tradeoffs arise.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Optimize for the end-user experience unless the cost violates an explicit constraint.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-fix-root-causes
|
|
3
|
+
description: Reproduce the symptom, trace causality until one mechanism explains it, and fix that mechanism rather than compensating for downstream effects. Use when during debugging and incident repair.
|
|
4
|
+
---
|
|
5
|
+
# Fix Root Causes
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
During debugging and incident repair.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Reproduce the symptom, trace causality until one mechanism explains it, and fix that mechanism rather than compensating for downstream effects.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-foundational-thinking
|
|
3
|
+
description: Choose the core data structures, ownership, and sequencing first so downstream logic becomes simpler. Use when before writing logic, especially when state or concurrency is involved.
|
|
4
|
+
---
|
|
5
|
+
# Foundational Thinking
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
Before writing logic, especially when state or concurrency is involved.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Choose the core data structures, ownership, and sequencing first so downstream logic becomes simpler.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-guard-the-context-window
|
|
3
|
+
description: Route bulk exploration to isolated workers or files and bring back compact evidence summaries, not raw floods. Use when when reads, logs, fan-out, or generated output threatens to dominate context.
|
|
4
|
+
---
|
|
5
|
+
# Guard the Context Window
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When reads, logs, fan-out, or generated output threatens to dominate context.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Route bulk exploration to isolated workers or files and bring back compact evidence summaries, not raw floods.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-laziness-protocol
|
|
3
|
+
description: Bias toward deletion and the smallest change that fully solves the problem. Use when considering adding code, abstractions, dependencies, or speculative features.
|
|
4
|
+
---
|
|
5
|
+
# Laziness Protocol
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When considering adding code, abstractions, dependencies, or speculative features.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Bias toward deletion and the smallest change that fully solves the problem.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-make-operations-idempotent
|
|
3
|
+
description: Design repeated execution to converge on the same correct end state rather than multiplying side effects. Use when for commands, lifecycle steps, retries, loops, or crash recovery.
|
|
4
|
+
---
|
|
5
|
+
# Make Operations Idempotent
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
For commands, lifecycle steps, retries, loops, or crash recovery.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Design repeated execution to converge on the same correct end state rather than multiplying side effects.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-migrate-callers-then-delete-legacy-apis
|
|
3
|
+
description: Move callers to the new shape and delete the old path in the same migration wave instead of carrying a compatibility layer. Use when when replacing an internal api.
|
|
4
|
+
---
|
|
5
|
+
# Migrate Callers Then Delete Legacy APIs
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When replacing an internal API.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Move callers to the new shape and delete the old path in the same migration wave instead of carrying a compatibility layer.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-minimize-reader-load
|
|
3
|
+
description: Reduce indirection, mutable scope, and one-caller abstractions until the causal path is easy to hold in one mind. Use when when code requires too many hops, wrappers, hidden states, or mental joins.
|
|
4
|
+
---
|
|
5
|
+
# Minimize Reader Load
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When code requires too many hops, wrappers, hidden states, or mental joins.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Reduce indirection, mutable scope, and one-caller abstractions until the causal path is easy to hold in one mind.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-model-the-domain
|
|
3
|
+
description: Encode the domain in the right structure: state machine, typed model, table, registry, reducer, boundary, or collection instead of scattered conditionals. Use when when stateful logic accumulates branches or repeated shape assumptions.
|
|
4
|
+
---
|
|
5
|
+
# Model the Domain
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When stateful logic accumulates branches or repeated shape assumptions.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Encode the domain in the right structure: state machine, typed model, table, registry, reducer, boundary, or collection instead of scattered conditionals.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-never-block-on-the-human
|
|
3
|
+
description: Run the experiment or make the reversible best-effort change, then show the result. Ask only for genuine preference, authority, or irreversible decisions. Use when when a reversible empirical or implementation choice can be resolved with available tools.
|
|
4
|
+
---
|
|
5
|
+
# Never Block on the Human
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When a reversible empirical or implementation choice can be resolved with available tools.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Run the experiment or make the reversible best-effort change, then show the result. Ask only for genuine preference, authority, or irreversible decisions.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-outcome-oriented-execution
|
|
3
|
+
description: Converge on the target architecture rather than preserving temporary compatibility states as permanent complexity. Use when during planned migrations or rewrites with explicit phases.
|
|
4
|
+
---
|
|
5
|
+
# Outcome-Oriented Execution
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
During planned migrations or rewrites with explicit phases.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Converge on the target architecture rather than preserving temporary compatibility states as permanent complexity.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-prove-it-works
|
|
3
|
+
description: Verify the requested behavior against the real artifact or surface whenever possible; a proxy check only proves the proxy. Use when verifying changes, completing tasks, or claiming something is fixed.
|
|
4
|
+
---
|
|
5
|
+
# Prove It Works
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When verifying changes, completing tasks, or claiming something is fixed.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Verify the requested behavior against the real artifact or surface whenever possible; a proxy check only proves the proxy.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-redesign-from-first-principles
|
|
3
|
+
description: Design the shape you would choose if the requirement had existed from day one, then migrate toward that shape. Use when when integrating a new requirement into a design that keeps fighting it.
|
|
4
|
+
---
|
|
5
|
+
# Redesign from First Principles
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When integrating a new requirement into a design that keeps fighting it.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Design the shape you would choose if the requirement had existed from day one, then migrate toward that shape.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-separate-before-serializing-shared-state
|
|
3
|
+
description: Eliminate unnecessary sharing or partition ownership before adding locks, queues, or coordination. Use when concurrency, locks, queues, shared state, or complex coordination are being considered.
|
|
4
|
+
---
|
|
5
|
+
# Separate Before Serializing Shared State
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When concurrency, locks, queues, shared state, or complex coordination are being considered.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Eliminate unnecessary sharing or partition ownership before adding locks, queues, or coordination.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-sequence-verifiable-units
|
|
3
|
+
description: Break work into small units that each end with a proof and order delivery so every next unit builds on verified state. Use when for migrations, sweeps, repeated edits, and stacks.
|
|
4
|
+
---
|
|
5
|
+
# Sequence Work into Verifiable Units
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
For migrations, sweeps, repeated edits, and stacks.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Break work into small units that each end with a proof and order delivery so every next unit builds on verified state.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-subtract-before-you-add
|
|
3
|
+
description: Remove dead weight and obsolete paths first; build on the simpler remaining system. Use when before an addition, rewrite, or structural refactor.
|
|
4
|
+
---
|
|
5
|
+
# Subtract Before You Add
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
Before an addition, rewrite, or structural refactor.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Remove dead weight and obsolete paths first; build on the simpler remaining system.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-test-behavior-not-implementation
|
|
3
|
+
description: Call the system the way its consumer does and assert meaningful observable output; avoid mocks or assertions that only mirror internal calls. Use when when writing or evaluating tests.
|
|
4
|
+
---
|
|
5
|
+
# Test Behavior, Not Implementation
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
When writing or evaluating tests.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Call the system the way its consumer does and assert meaningful observable output; avoid mocks or assertions that only mirror internal calls.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: principle-type-system-discipline
|
|
3
|
+
description: Make invalid states hard or impossible to represent and parse external primitives into meaningful internal types at the edge. Use at data modeling, API design, or external data ingestion points.
|
|
4
|
+
---
|
|
5
|
+
# Type System Discipline
|
|
6
|
+
|
|
7
|
+
## Trigger
|
|
8
|
+
|
|
9
|
+
At data modeling, API design, or external data ingestion points.
|
|
10
|
+
|
|
11
|
+
## Rule
|
|
12
|
+
|
|
13
|
+
Make invalid states hard or impossible to represent and parse external primitives into meaningful internal types at the edge.
|
|
14
|
+
|
|
15
|
+
## Application
|
|
16
|
+
|
|
17
|
+
1. Name the concrete decision this principle changes.
|
|
18
|
+
2. Apply the rule to that decision, not as a decorative citation.
|
|
19
|
+
3. Prefer evidence from the current repository/runtime over generic preference.
|
|
20
|
+
4. If the principle conflicts with an explicit user constraint, keep the constraint and state the tradeoff.
|
|
@@ -0,0 +1,13 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: recall
|
|
3
|
+
description: Reconstruct current task context from available durable history and records. Use when resuming work or rebuilding context on a topic.
|
|
4
|
+
---
|
|
5
|
+
# Recall
|
|
6
|
+
|
|
7
|
+
Rebuild context from durable evidence, not memory theater.
|
|
8
|
+
|
|
9
|
+
1. Search the sources the host actually exposes: prior chats, decision logs, issues/PRs, branches, commits, docs, or task files.
|
|
10
|
+
2. Prefer recent primary artifacts over summaries.
|
|
11
|
+
3. Reconcile contradictions against repository/current external state.
|
|
12
|
+
4. Return a compact brief: goal, current state, decisions, completed work, open risks, next verified step, and source pointers.
|
|
13
|
+
5. If history access is unavailable, say which source is missing rather than fabricating a recollection.
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: reflect
|
|
3
|
+
description: Convert lessons from a completed difficult task into structural improvements. Use after a long or unexpectedly painful workflow.
|
|
4
|
+
---
|
|
5
|
+
# Reflect
|
|
6
|
+
|
|
7
|
+
1. Compare the intended workflow with what actually happened using the decision log, diff, test history, and failures.
|
|
8
|
+
2. Identify repeated waste, missing checks, bad assumptions, and the earliest point each could have been caught.
|
|
9
|
+
3. Prefer structural fixes: scripts, tests, metadata, better boundaries, or narrower skill triggers. Add prose only when it is the right lever.
|
|
10
|
+
4. Change the smallest reusable artifact that prevents recurrence.
|
|
11
|
+
5. Re-run the scenario or a focused eval to prove the reflection improved behavior.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: setup-pstack
|
|
3
|
+
description: Configure potetos-for-everyone model roles and capability preferences for the current agent/runtime. Use during initial setup or routing changes.
|
|
4
|
+
---
|
|
5
|
+
# Setup pstack, portable
|
|
6
|
+
|
|
7
|
+
1. Detect host capabilities and available model/delegation options. Do not assume model names.
|
|
8
|
+
2. Explain the optional roles: fast mechanical worker, strongest judgment worker, prose/document worker, and review panel.
|
|
9
|
+
3. If the host has native delegation, record only routing preferences. If it lacks delegation but agent CLIs are available, configure portable runner profiles using `runtime/config.example.json`; keep secrets in environment variables, not the config file.
|
|
10
|
+
4. Write only explicit overrides to `.potetos/config.json`. Missing roles/runners mean inherit the host/parent behavior.
|
|
11
|
+
5. Validate the config as JSON and make sure canonical skills remain model-agnostic.
|
|
12
|
+
6. Run the installer doctor and a dry invocation of `poteto-mode` discovery. If external runners were configured, run a harmless one-line delegate smoke test.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: show-me-your-work
|
|
3
|
+
description: Maintain a compact auditable decision trail during autonomous or high-stakes work. Use when the user will review decisions later.
|
|
4
|
+
---
|
|
5
|
+
# Show Me Your Work
|
|
6
|
+
|
|
7
|
+
Keep `.potetos/decisions.tsv` with columns:
|
|
8
|
+
|
|
9
|
+
`timestamp\tunit\tdecision\tevidence\talternatives\tverification\trevision`
|
|
10
|
+
|
|
11
|
+
Rules:
|
|
12
|
+
|
|
13
|
+
1. Log decisions that materially change scope, architecture, risk, or the next unit. Do not log every command.
|
|
14
|
+
2. Use stable file/commit/test/URL references in evidence fields when available.
|
|
15
|
+
3. Record rejected alternatives briefly enough to explain why the chosen path won.
|
|
16
|
+
4. Update verification after the evidence exists; never pre-fill success.
|
|
17
|
+
5. Keep secrets and private transcript content out of committed logs.
|
|
@@ -0,0 +1,12 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: swarm
|
|
3
|
+
description: Fan out independent slices or coverage partitions and aggregate them with owner verification. Use for large audits, races, and parallel work.
|
|
4
|
+
---
|
|
5
|
+
# Swarm
|
|
6
|
+
|
|
7
|
+
1. Define a partition with minimal shared mutable state and one owner per slice.
|
|
8
|
+
2. Give every worker exact scope, output schema, evidence requirements, and stop condition.
|
|
9
|
+
3. Use isolated `delegate` workers when available. If not, execute slices sequentially and label the fallback.
|
|
10
|
+
4. Collect artifacts and evidence, not only prose summaries.
|
|
11
|
+
5. The parent reconciles overlap, conflicts, and missing coverage, then independently checks high-impact findings or integrations.
|
|
12
|
+
6. Return one deduplicated result and a coverage map.
|