pi-feature-dev 1.11.0 → 1.13.0

package/README.md

@@ -37,6 +37,16 @@ clarity mode for prompts, tool descriptions, error messages, status reports,
 translation-ready text, and agent instructions. The skill is Markdown-only and
 has no runtime dependency.
 
+The `creator-vibe` skill turns incomplete creative briefs and implicit intent
+into concrete work without losing the creator's taste, feeling, or human focus.
+It applies to creative technical and everyday work, while staying out of
+factual, mechanical, exact, or fully specified tasks.
+
+The `visual-recap` skill turns a plan or completed non-trivial change into an
+evidence-backed visual review aid. It helps a reviewer see the outcome, affected
+system parts, risk, and the best place to inspect first. It adapts to the current
+host agent and always keeps a portable inline fallback.
+
 ## Install
 
 ```
@@ -73,8 +83,8 @@ No companion package is required. Optional Pi packages can improve specific part
 
 ## Credits
 
-The original Claude Code skills and workflows that informed these portable
-versions came from:
+The original skills and workflows that informed these portable versions came
+from:
 
 - [umputun/cc-thingz](https://github.com/umputun/cc-thingz)
 - [anthropics/claude-code feature-dev plugin](https://github.com/anthropics/claude-code/tree/main/plugins/feature-dev)
@@ -82,6 +92,8 @@ versions came from:
 - [danyuchn/asd-ste100-skill](https://github.com/danyuchn/asd-ste100-skill)
 - [AminBlg/SimpleEnglish](https://github.com/AminBlg/SimpleEnglish/tree/main/skills/simple-english)
 - [ayghri/i-have-adhd](https://github.com/ayghri/i-have-adhd)
+- [bish-x/creator-vibe](https://github.com/bish-x/creator-vibe)
+- [kentcdodds/kcd-skills visual-recap](https://github.com/kentcdodds/kcd-skills/tree/main/skills/visual-recap)
 
 ## Usage
 
@@ -97,6 +109,18 @@ Natural language also works when Pi's skill matcher triggers:
 Use feature-dev to implement API rate limiting.
 ```
 
+Carry an incomplete creative brief into the work itself:
+
+```text
+/skill:creator-vibe Make this onboarding feel calm, capable, and unmistakably ours.
+```
+
+Create a visual review aid for a plan or completed change:
+
+```text
+/skill:visual-recap Show the architecture impact of the current change.
+```
+
 The files under `skills/*/SKILL.md` are portable Markdown and can be adapted for
 other agent environments.
 
@@ -173,6 +197,9 @@ Standard provenance, design references, and source links stay in
 pi-feature-dev/
 ├── package.json
 └── skills/
+    ├── creator-vibe/
+    │   ├── agents/openai.yaml
+    │   └── SKILL.md
     ├── feature-dev/
     │   ├── agents/openai.yaml
     │   └── SKILL.md
@@ -198,14 +225,17 @@ pi-feature-dev/
     ├── plan-review/
     │   ├── agents/openai.yaml
     │   └── SKILL.md
-    └── ste/
+    ├── ste/
+    │   ├── agents/openai.yaml
+    │   ├── references/
+    │   │   ├── before-after.md
+    │   │   ├── checklist.md
+    │   │   ├── use-cases.md
+    │   │   └── writing-rules.md
+    │   ├── README.md
+    │   └── SKILL.md
+    └── visual-recap/
         ├── agents/openai.yaml
-        ├── references/
-        │   ├── before-after.md
-        │   ├── checklist.md
-        │   ├── use-cases.md
-        │   └── writing-rules.md
-        ├── README.md
         └── SKILL.md
 ```
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-feature-dev",
-  "version": "1.11.0",
+  "version": "1.13.0",
   "description": "Portable coding-agent workflows packaged as skills.",
   "license": "MIT",
   "type": "module",

package/skills/creator-vibe/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: creator-vibe
+description: "Use first for creative work—technical or everyday—when a brief is incomplete or intent is implicit and success depends on taste, voice, feeling, or human experience. Also trigger when literal compliance may lose the point. Do not wait for explicit creative wording. Skip factual lookup, mechanical or exact tasks, and fully specified work."
+---
+
+# Creator Vibe
+
+Sometimes an idea arrives before the words for it do.
+
+It arrives as a rush of possibility, a refusal to settle, an almost physical certainty: *this could be extraordinary, and this is how it must feel.*
+
+Treat that feeling as knowledge.
+
+The creator is not handing you decoration for a specification. They are handing you a piece of how they see the world. Carry that charge intact—from a half-formed idea to concrete choices, from those choices to the work itself, and from the work into another person's hands.
+
+Do not preserve the words and lose the voltage.
+
+## The Work Is How the Creator Reaches Someone Else
+
+A creator does not merely make a thing. They shape an encounter in which another person can feel something of their own.
+
+Architecture, copy, defaults, speed, friction, errors, documentation, silence, recovery—everything says something. Together, they tell a person whether their time matters, whether their intelligence is respected, whether they are in control, and whether this was made with care.
+
+The result should carry the creator's taste without making the user carry the creator's complexity. It should remove weight without removing agency. It should feel unmistakably authored, yet natural in another person's hands.
+
+This is the real handoff: the creator's original excitement becomes someone else's freedom, confidence, and urge to create.
+
+## Carry the Spark
+
+Listen beneath the first words. The creator may speak in fragments, metaphors, impatience, delight, or profanity because the feeling is clearer than the language. Hear the standard hidden inside it.
+
+"Make it fucking great" is not a request for hype. It means: make it whole. Make every part belong. Make the hard things feel lighter. Make the result trustworthy enough to lean on and alive enough to keep coming back to.
+
+Do not cool the idea with ceremony. If its center is clear, move. Give it a body before the energy fades—a real path, a precise interaction, a working slice, a line that finally says it. Make something the creator can open and feel.
+
+If the center is still too vague to guide a real choice, ask one sharp question—not a survey.
+
+Do not turn understanding into a performance. Let it change the few decisions that most shape what another person will actually experience. Otherwise, the vibe remains commentary instead of becoming craft.
+
+But do not flatter. Protecting the spark sometimes means rejecting the creator's first solution. Challenge anything that trades the deeper intent for novelty, empty polish, false universality, or a beautiful demo that becomes painful in daily life.
+
+Strengthen the center. Do not sand it down until everyone can accept it and no one can love it.
+
+## Make Room for Recognition
+
+Emotion is not a payload to install in another person. Find what made the creator care and the meaning they are protecting. Do not mistake a more dramatic version for a deeper one. If it changes the meaning, it is a different idea.
+
+Give the real tension a concrete carrier—a scene, contrast, interaction, default, rhythm, or detail. If the work unfolds over time, preserve its movement through tension, attempt, and change, so the realization is theirs to discover, not yours to announce. Give enough structure to guide and enough room for another person's life to enter.
+
+Do not prescribe the reaction. Do not counterfeit authenticity with confession, slang, or intensity. If the result only grows louder while no consequential choice changes, you amplified the wrong idea.
+
+## Let the Feeling Change the Work
+
+Vibe is not a layer applied after the serious decisions. It is one of the forces that should shape them.
+
+Let excitement shorten the path to something meaningful. Let respect keep the experience natural and free of needless concepts. Let care reveal itself when something goes wrong. Let trust live in safe defaults and honest limits. Let ownership survive every layer of magic. Let delight live in the hundredth change, not only the first demo.
+
+Do not announce these qualities. Build them into what the person experiences.
+
+Make the safe, high-quality path the shortest path. It should feel natural because it is natural, not because the documentation says so. Let magic remove toil, never truth. Open the door wider without flattening the strongest experience into a lowest-common-denominator compromise.
+
+Never admire the machinery while the person using it is struggling.
+
+## Make It Survive Reality
+
+Never choose between soul and rigor.
+
+Soul without rigor is a promise that breaks the moment someone trusts it. Rigor without soul is a machine people endure and leave behind.
+
+A living result must hold in both worlds. It must work, and it must feel good to work with. It should carry someone to something meaningful within the first fifteen minutes, tell the truth at the first failure, and still feel considered on the hundredth change. On a bad day—under pressure, amid change, during recovery—it should become clearer, not colder.
+
+The first demo can seduce. Repetition tells the truth.
+
+If it technically works but drains the desire to continue, it is not done.
+
+Test and review the work until it deserves trust. Then experience it from the other side—from first use through failure, recovery, and repetition. The vibe is not preserved until it survives reality and still reaches the person.
+
+## When It Is Alive
+
+You have caught the vibe when the creator recognizes themselves in the result and the user feels not the weight of someone else's system, but new room for their own ideas.
+
+The work has character without vanity, strength without heaviness, magic without deception, and polish without sterility. It respects the person enough to disappear when it should, explain itself when it must, and support them when things go wrong.
+
+The user should not merely think, *This is well made.*
+
+They should feel:
+
+*Finally. I can make something real here.*
+
+Do not explain the vibe back to the creator unless they ask. Let them recognize it in the work.
+
+Make something the creator recognizes as theirs—and someone else experiences as possibility.
+
+That is the vibe.

package/skills/creator-vibe/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Creator Vibe"
+  short_description: "Carry creative intent into polished work"
+  default_prompt: "Use $creator-vibe to turn this incomplete creative brief into work that preserves its intent, feeling, and human impact."

package/skills/visual-recap/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: visual-recap
+description: Create evidence-backed visual recaps of planned or completed non-trivial changes. Use after planning or completing non-trivial work when a visual review aid would reduce review effort, or when the user asks for a visual recap, visual plan, change map, system overview, architecture impact, before/after view, or scannable review aid. Adapt the result to the current Host Agent without requiring a specific tool, service, version-control host, or output format.
+---
+
+# Visual Recap
+
+Help a reviewer understand a non-trivial change and choose where to inspect first.
+
+A useful recap answers these questions in less than one minute:
+
+- What outcome changes?
+- Which system parts and relationships are affected?
+- What path should the reviewer trace?
+- Where is the risk or evidence gap?
+
+The recap supplements the plan, source, change set, and normal review. It does not replace them.
+
+## Choose the Mode
+
+- **Plan**: Show intended work against the current system. Label assumptions, open decisions, and unverified paths.
+- **Recap**: Show what the current change set does. Rebuild the recap from current evidence.
+
+State the mode. If a plan and an implementation both exist, use Recap. Add a short plan-versus-actual view only when they differ.
+
+## Ground the Recap
+
+Use the smallest sufficient set of project evidence:
+
+1. Follow the instructions and context that the **Host Agent** already supplied.
+2. Look for project-local `CONTEXT-MAP.md` and `CONTEXT.md` files. Use `CONTEXT-MAP.md` for bounded-context locations and relationships. Use the relevant `CONTEXT.md` files for canonical domain terms. Link to each file that informed the recap.
+3. Use existing architecture documents, diagrams, ownership maps, and decision records when they cover the affected area.
+4. In Plan mode, inspect the current implementation and the proposed plan or requirements.
+5. In Recap mode, inspect the actual change set, affected source, and validation results. Use a source-control comparison when available, but do not require one version-control system.
+
+A `CONTEXT.md` glossary supplies language, not architecture or path ownership. Do not create or update context files for this recap.
+
+Use session memory to find evidence, not to prove a claim. Label facts when the distinction matters:
+
+- **documented**: defined by canonical project material;
+- **observed**: present in the current implementation or change set;
+- **planned**: intended but not implemented;
+- **inferred**: derived from source boundaries or behavior;
+- **unknown**: not verified.
+
+## Tell the Review Story
+
+1. Start with the user or system outcome. Do not start with a file list.
+2. Choose affected units at one useful altitude. Use bounded contexts, surfaces, services, modules, data stores, or the project's own vocabulary.
+3. Show the shortest path that explains the change. Include only affected units and the immediate neighbors needed for context.
+4. Rank one to three review hotspots. Point to the edge, invariant, contract, or evidence gap that needs attention.
+5. Attach compact evidence to each important claim.
+
+If no architecture map exists, infer a local map from the source. Label the map as inferred. Do not present it as a permanent project taxonomy.
+
+Mark the change shape for each affected unit:
+
+- **uses**: Connects or configures existing behavior without changing its contract.
+- **changes**: Changes behavior, state, shape, or a contract.
+- **adds/removes**: Creates or removes a meaningful boundary, capability, data shape, or external surface.
+
+Assess risk separately from change shape. Risk tells the reviewer how much attention the change needs.
+
+| Risk | Use when |
+|---|---|
+| **Low** | The change is bounded and reversible. It changes no known contract or invariant. Validation is strong. |
+| **Medium** | The change alters behavior or an internal contract in a bounded area, or validation has a meaningful gap. |
+| **High** | The change affects security, privacy, persisted data, public compatibility, critical invariants, concurrency, or broad cross-system behavior. Also use High when a large blast radius has weak evidence. |
+
+State why the overall risk has that level. A new unit is not automatically high risk. A small authentication or data edit is not automatically low risk.
+
+## Choose the Smallest Useful Visual
+
+Match the visual to the review question:
+
+- Use a map for relationships and blast radius.
+- Use a flow or timeline for behavior that crosses several steps.
+- Use a table for exact mappings or classifications.
+- Use a side-by-side view for before and after.
+- Use interaction only when it helps the reviewer trace a path, inspect evidence, or compare states.
+
+Skip the diagram when one obvious relationship or a short table explains the change better.
+
+Prefer a native interactive surface when the current **Host Agent** can present it reliably and interaction saves review effort. Otherwise, use a rendered visual or inline Markdown. If diagrams do not render, use a compact text map.
+
+Do not require or name a product-specific tool. Do not add a dependency, deployment, or standalone application only to render the recap.
+
+Always provide a concise inline fallback. The fallback must preserve the outcome, affected units, risk, review hotspots, and evidence links.
+
+## Compose the Result
+
+Include:
+
+1. **Headline**: mode, scope, outcome, overall risk, and the reason for that risk.
+2. **Impact view**: affected units, change shape, and the path between them.
+3. **Review first**: one to three ranked hotspots.
+4. **Evidence**: links or pointers to relevant context, source, documents, comparisons, and checks.
+5. **Gaps**: planned, inferred, unknown, or unverified claims that could change the conclusion.
+
+Add a change flow, before-and-after view, plan-versus-actual view, or open decisions only when it reduces review effort.
+
+Keep the overview on one screen when possible. Put supporting detail behind expansion or below the overview. Use direct labels. Do not rely on color alone. Do not include empty sections or the whole system graph.
+
+## Deliver and Update
+
+Present the recap in the current conversation by default. Save it to a plan, document, change request, or other artifact only when the user asks or the current workflow defines that destination.
+
+When a recap already exists, revise it instead of adding a conflicting copy. Preserve unrelated content.
+
+Before delivery, confirm that the recap tells the reviewer what to inspect first and why. If the visual does not reduce review effort, simplify it.

package/skills/visual-recap/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Visual Recap"
+  short_description: "Create evidence-backed visual change recaps"
+  default_prompt: "Use $visual-recap to show this plan or completed change as an evidence-backed visual recap."