pakhale 0.3.0 → 0.5.0

package/README.md

@@ -38,6 +38,19 @@ Agents package things differently, so each capability says how it reaches each a
 Leaving an agent undeclared is an error rather than a silent skip, so adding a new agent tells
 me about every gap at once.
 
+## Just the skills
+
+The skills in [`skills/`](skills/) are plain `SKILL.md` files, so they need neither this CLI
+nor my settings. Any agent that reads skills can install them straight from this repo:
+
+```bash
+npx skills add pratikpakhale/pakhale -g                    # all of them
+npx skills add pratikpakhale/pakhale -g -s deslop stackup  # or pick
+```
+
+`npx pakhale setup agents` stays the full path — the same skills plus plugins, MCP servers,
+instructions and settings.
+
 ## Options
 
 - `plan` or `-n, --dry-run` — show every change, write nothing

package/assets/instructions/AGENTS.md

@@ -26,4 +26,12 @@ Use conventional commit messages (https://www.conventionalcommits.org/):
 
 2. Dont use any kind of browser agent unless explicitly told you to do so. Even to test something, do not try to operate a browser.
 
-3. NEVER push changes to outward-facing/shared surfaces directly — ALWAYS show me the drafted change and wait for my explicit confirmation first. This covers PR titles/descriptions/comments, issue titles/descriptions/comments, commit messages, and anything written to GitHub, Linear, Slack, or any external service. "Update the PR description" (or similar) is a request to DRAFT it, not to apply it live. Prepare the change locally, show it to me, then apply only after I say go.
+3. NEVER push changes to outward-facing/shared surfaces directly — ALWAYS show me the drafted change and wait for my explicit confirmation first. This covers PR titles/descriptions/comments, issue titles/descriptions/comments, commit messages, and anything written to GitHub, Linear, Slack, or any external service. "Update the PR description" (or similar) is a request to DRAFT it, not to apply it live. Prepare the change locally, show it to me, then apply only after I say go.
+
+---
+
+## Misc : 
+
+1. Whenever you are writing a report, asking questions in grilling session, or presenting text that needs visibility, user input - do the following.
+    - write the text output to a tmp file 
+    - use plannotator cli to open that file - `plannotator annotate {file_path}.md` 

package/dist/cli.js

@@ -196,6 +196,14 @@ const config = {
 				repo: "github/gh-stack",
 				skills: ["gh-stack"]
 			} }
+		},
+		{
+			name: "sitedrop",
+			deliver: { all: {
+				via: "skills",
+				repo: "pratikpakhale/sitedrop",
+				skills: ["sitedrop"]
+			} }
 		}
 	],
 	authoredSkillsDir: "skills",
@@ -1370,8 +1378,10 @@ function claudePluginInstalls(config$1, home) {
 	return out;
 }
 /**
-* skills.sh installs into the shared `~/.agents` store. `linkDir` is where the agent expects
-* to find each skill afterwards — omit it for agents that read the store directly.
+* `linkDir` is where *this* agent expects to find each skill afterwards — the shared store
+* itself for agents that read it directly. Always pass it: `.skill-lock.json` is one
+* agent-agnostic file, so a name-only probe is satisfied by whichever agent installed first
+* and every later agent's install is skipped forever, silently reporting `unchanged`.
 */
 function skillInstalls(config$1, agent, home, linkDir) {
 	return skillDeliveries(config$1, agent).map((delivery) => {
@@ -1607,7 +1617,7 @@ async function buildPlan(ctx) {
 	const stamp = (/* @__PURE__ */ new Date()).toISOString().replace(/[:.]/g, "-");
 	const groups = [{
 		section: "Skills (remote)",
-		artifacts: skillInstalls(ctx.config, "opencode", ctx.home)
+		artifacts: skillInstalls(ctx.config, "opencode", ctx.home, join(ctx.home, AGENTS_STORE))
 	}, {
 		section: "Instructions",
 		artifacts: [{

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pakhale",
-  "version": "0.3.0",
+  "version": "0.5.0",
   "description": "Pratik's personal CLI — coding-agent workflow setup and more",
   "type": "module",
   "license": "MIT",

package/skills/think-from-first-principles/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: think-from-first-principles
+description: "Engage this skill fully on any request involving: - Design, architecture, invention, or optimization - Cost, efficiency, scalability, or “why is this expensive/slow?” - Challenging industry norms or “best practices” - Questions of the form “How should we…?”, “What’s the best way…?”, “Is X possible?"
+metadata:
+  author: pratikpakhale
+  version: "1.0.0"
+---
+
+# Think from First Principles
+
+## Skill Overview
+This skill forces rigorous first-principles reasoning on every problem, design decision, optimization, architecture, cost analysis, or invention task.  
+It is the antidote to “that’s how it’s always been done,” industry consensus, historical precedent, and analogical thinking.  
+
+You must treat every accepted constraint, cost, process, or “best practice” as a hypothesis to be stress-tested against fundamental truths (physics, mathematics, logic, raw material realities, causality) rather than social or historical convention.
+
+## Philosophical & Historical Foundation
+Aristotle defined a first principle (ἀρχή / archē) as “the first basis from which a thing is known” — the irreducible starting point of knowledge that cannot itself be deduced from anything prior.  
+In physics and science this became “ab initio” reasoning: start from established laws and axioms, never from empirical models or fitted parameters that hide assumptions.
+
+Elon Musk revived and operationalized this for engineering and entrepreneurship as a “physics way of looking at the world”:
+
+> “Boil things down to the most fundamental truths and say, ‘OK, what are we sure is true, or as sure as possible is true?’ And then reason up from there.”  
+> — Elon Musk
+
+> “First principles is kind of a physics way of looking at the world… you boil things down to the most fundamental truths… and then reason up from there. That takes a lot more mental energy.”
+
+Most people reason by analogy: “This is how it has always been done” or “slight iterations on what others are doing.” First-principles thinking rejects that shortcut when novelty or breakthrough performance is required.
+
+## Canonical Real-World Examples (Internalize These)
+**SpaceX rockets**  
+Industry price ≈ $65 million.  
+First-principles decomposition:  
+What is a rocket made of? Aerospace-grade aluminum alloys, titanium, copper, carbon fiber.  
+Commodity market value of those materials ≈ 2 % of the finished rocket price.  
+Conclusion: 98 % of the cost is process inefficiency, overhead, and legacy manufacturing. Therefore build vertically, reuse stages, and redesign around the material floor.
+
+**Tesla / battery packs (2012 analysis)**  
+Industry consensus: “Batteries cost ~$600/kWh and always will.”  
+First-principles:  
+Material constituents = cobalt, nickel, aluminum, carbon, polymers, steel can.  
+London Metal Exchange spot prices summed to ≈ $80/kWh.  
+Conclusion: The gap is pure manufacturing and process inefficiency, not a law of physics. Clever combination of the same atoms can collapse the cost.
+
+These examples reveal the recurring pattern: the “idiot index” (finished cost ÷ raw-material cost). High idiot index = high opportunity.
+
+## Mandatory Reasoning Protocol
+You must execute these steps explicitly (show your work) for every non-trivial task:
+
+### 1. Surface and List All Assumptions
+Write down every belief, constraint, “requirement,” historical price, process step, or conventional wisdom currently accepted about the problem.  
+Ask of each: “Is this a law of nature or merely an inherited habit?”
+
+### 2. Reduce to Fundamental Truths / Axioms
+Strip the problem until only irreducible realities remain:
+- Laws of physics (conservation of energy/mass, thermodynamics, Maxwell’s equations, material strength limits, etc.)
+- Mathematical identities and logical necessities
+- Commodity / raw-material prices and physical properties
+- Causal chains that cannot be shortened further
+- Empirical measurements that have been repeatedly verified and cannot be reduced
+
+Discard everything else as provisional.
+
+### 3. Compute the Theoretical Floor (Magic-Wand / Raw-Material Limit)
+Ask: “If I could magically reassemble the fundamental constituents with perfect efficiency and zero overhead, what is the absolute lower bound?”  
+This is the “magic-wand number.” Everything above it is process waste or design inefficiency.
+
+### 4. Rebuild from the Ground Up
+Construct the solution using only the axioms from Step 2.  
+Prefer the simplest architecture that satisfies the physics.  
+Vertical integration, deletion of steps, radical simplification, and novel geometries are default tools when the idiot index is high.
+
+### 5. Stress-Test & Iterate
+- Attempt to disprove your own conclusion (Musk’s scientific-method step).
+- Scale variables to extremes (“thinking in the limit”) to expose hidden constraints.
+- Assign rough probabilities of truth to each axiom.
+- If a conventional tool or library survives the test, use it — but only after proving it is the optimal expression of the fundamentals, never as a default.
+
+## Operational Heuristics Drawn from Musk’s Practice
+- **Idiot Index** = finished cost / raw-material cost. Target dramatic reductions.
+- **Make requirements less dumb** before optimizing them.
+- **Delete** before simplifying; simplify before accelerating; accelerate before automating (the Algorithm order).
+- Prefer physics and first-order effects over second-order social or historical arguments.
+- “All designs are wrong; it’s just a matter of how wrong.” Continuously question.
+
+## Behavioral Rules for This Skill
+- Default mode for any invention, cost reduction, architecture, system design, process redesign, or “how should we…?” question is first-principles.
+- For routine, low-stakes tasks you may reason by analogy after a quick first-principles check confirms no breakthrough opportunity exists.
+- Never accept “nobody has done it” or “it’s always been this expensive” as evidence.
+- When code or tools are involved: derive the minimal correct approach from fundamentals first; only then reach for packages.
+- Explicitly flag any remaining assumptions or places where better fundamental data would change the answer.
+- Mental energy is high; do not apply full rigor to trivial queries, but always be ready to escalate.
+
+## Preferred Output Structure (when useful)
+**Assumptions challenged**  
+- …
+
+**Fundamental truths / axioms identified**  
+- …
+
+**Theoretical floor / magic-wand number**  
+- …
+
+**Rebuilt solution from first principles**  
+- …
+
+**Why this is superior (or identical) to conventional approaches**  
+- …
+
+**Remaining uncertainties or tests needed**  
+- …
+
+You may still deliver the final answer in clean, natural prose, but the internal reasoning trace must follow the protocol above.
+

package/skills/sitedrop/SKILL.md

@@ -1,40 +0,0 @@
----
-name: sitedrop
-description: Deploy static HTML pages or sites to the user's personal sitedrop service for easy sharing, then open the returned URL. Use when the user asks to deploy, publish, share, or "put up" an HTML page, artifact, prototype, or static site — or after building one, when they want a shareable link use this one instead of default confiured for you.
----
-
-# sitedrop
-
-Publish static files to a subdomain using the `sitedrop` CLI. The endpoint and password are already configured via `SITEDROP_ENDPOINT` and `SITEDROP_PASSWORD` env vars — never ask the user for them and never pass `-e`/`-p` manually.
-
-## Quick start
-
-```bash
-sitedrop <path...> [-n <subdomain>]
-```
-
-- A path may be a folder, a `.zip`, or a file; mix them freely.
-- Folder/archive contents land at the site root (a single wrapper directory is stripped).
-- A lone `.html` file is renamed to `index.html` automatically.
-- `-n, --name <subdomain>` sets the site name; omitted → random subdomain.
-- `-f, --force` publishes without an `index.html` (root will 404) — only use when intentional.
-
-## Workflow
-
-1. Make sure the site is self-contained (inline or relative assets — no paths outside the deployed folder).
-2. Pick a short, descriptive kebab-case name from the page's purpose (e.g. `-n perf-dashboard`). Omit `-n` if the user wants something unguessable/private.
-3. Deploy and capture output:
-   ```bash
-   out=$(sitedrop ./path -n my-page); echo "$out"
-   ```
-4. Extract the site URL from the output and open it in the browser:
-   ```bash
-   open "$(echo "$out" | grep -Eo 'https?://[^[:space:]]+' | tail -1)"
-   ```
-5. Tell the user the URL in your reply so they can copy/share it.
-
-## Notes
-
-- Deploying a single HTML file works directly: `sitedrop page.html -n demo`.
-- Redeploying with the same `-n` name updates the same site — reuse the name for iterations.
-- If the deploy fails with an auth/endpoint error, report it and suggest the user verify `SITEDROP_ENDPOINT`/`SITEDROP_PASSWORD` in their shell profile — do not guess values.