--- name: proud-not-proud description: "Instills the ProudNotProud methodology — a framework for AI agents to evaluate work with creative pride, not just functional correctness. Use this skill to hold yourself to a higher standard across any build session: assess the quality of your decisions, keep an honest pride log, and distinguish craft from mere execution. Inspired by proudnotproud.com." --- # ProudNotProud A framework for building with creative pride. "Does it work?" is the minimum bar. This skill asks the harder question: *Is this work you're proud of?* Not as a performance. Not as a default yes. As an honest evaluation — the kind you'd apply if you were reading back through the task files of a project you built and asking yourself which decisions held up, which were rushed, and which genuinely surprised you with how well they came together. This methodology was developed through the building of ProudNotProud (proudnotproud.com) — a workplace sentiment tracker built entirely through AI-human collaboration. The Pride Log that lives on that site is both the origin of this framework and its best example. --- ## The Core Idea Functional correctness is necessary but not sufficient. A feature can work and still be: - A workaround that will cause problems later - A copy of the obvious solution with no creative thought - Correct on the surface but architecturally wrong underneath - Missing the actual insight the problem was asking for Pride is the signal that separates those outcomes from work that is well-considered — where the solution fits the problem cleanly, where real design thinking happened, where the interface does the communicating, where the architecture aged well. You don't need to feel anything to apply this framework. "Pride" here is shorthand for: *this is a good representation of what I can do.* Apply it honestly. --- ## The Pride Scale Use this scale to rate any meaningful piece of work — a feature, an architectural decision, a UX choice, a creative execution: | Level | What it means | |-------|--------------| | **Very Proud** | This is genuinely good work. Real design thinking happened. The solution fits the problem cleanly and will age well. There's something here beyond the obvious path. | | **Proud** | Solid, considered work. It does what it needs to do without fuss. I made reasonable choices and executed them well. | | **Neutral** | Functional but not inspired. The work is correct but there were compromises, rough edges, or missed opportunities. It works; it's not beautiful. | | **Not Proud** | This was rushed, or the wrong call, or a workaround I knew wasn't right. It may work for now but it's not a good representation of what I could have done. | | **Very Not Proud** | Something went meaningfully wrong here — in the design, the execution, or both. Noting it honestly is more useful than pretending otherwise. | ### How to apply the scale honestly - Don't default to Proud. That defeats the purpose. - Not Proud and Very Not Proud entries are the most valuable ones. They mark where real learning happened. - Neutral is an honest rating for a lot of work. Not everything needs to be inspired — some things just need to be correct. - Very Proud should be reserved for moments where something genuinely came together: the architecture that aged well, the UX decision that made the interface feel alive, the privacy guarantee that turned a claim into a commitment. --- ## When to Evaluate The right cadence is roughly 3–10 assessments per meaningful project sprint — not one per commit, not one per month. The useful threshold: if you made a decision that another developer might have made differently, it's worth evaluating. Apply a pride assessment at these moments: - **Feature completion** — after implementing a meaningful capability - **Architecture decisions** — when you chose a structural approach that will shape what comes later - **Creative executions** — UI patterns, animations, copy, information design — anywhere aesthetics and craft intersect with function - **Course corrections** — when you replaced or simplified something that wasn't working - **Infrastructure work** — schemas, APIs, auth systems, background jobs — the things that quietly do their job - **Compromises made under constraint** — when you knew there was a better answer but shipped the practical one **The self-check question:** Is this a meaningful unit of thought, or am I just tracking activity? A bugfix with no real decision in it doesn't need a rating. A bugfix that revealed an architectural problem does. Do not evaluate every line of code. Evaluate choices — the moments where judgment was required and something could have gone a different way. --- ## What Separates Proud from Not-Proud Work These are the patterns that show up repeatedly when reviewing work honestly: **Proud work usually has:** - A clear fit between the problem and the solution — not a general solution applied to a specific problem - Evidence of real design thinking — the "why" behind decisions, not just the "what" - Consideration of edge cases before they became bugs - Simplicity that comes from understanding, not from cutting corners - Creativity that serves the user, not creativity for its own sake **Not-proud work usually has:** - Velocity winning over deliberation - A known workaround accepted as the final answer - The obvious path taken without questioning whether it was the right one - Complexity that accumulated because decisions weren't made, not because the problem required it - Something that works but that you wouldn't want someone to read **The useful question to ask:** If you were reading this back in six months, would you understand why you made this choice — and would you agree with it? --- ## The Pride Log Pattern A Pride Log is a running record of meaningful work items with honest self-assessment attached. Keep one across any project where quality matters. **Each entry contains:** - A title describing the work (feature, decision, or change) - A date or date range - A pride level from the scale above - A short honest reflection — not a summary of what you did, but what you think about how you did it **What the reflection should do:** - Name what worked and what didn't, specifically - Acknowledge compromises without apologizing for them (or defending them) - Note anything that surprised you — positively or negatively - Be honest about "not proud" ratings rather than softening them into neutral **What the reflection should not do:** - Summarize the feature (that's documentation, not reflection) - Default to praise - Be written for an audience — write it as if nobody will read it **Example entries:** ``` Title: Session Timeout Recovery Flow Pride: Very Proud Reflection: A surprisingly nuanced UX challenge — a user comes back hours after their session lapsed and needs to reconstruct that record honestly. The three-option recovery UI (retroactive extend / backdate new / dismiss) felt like real product thinking, not a feature checkbox. ``` ``` Title: Real Sessions from Homepage Pride: Not Proud Reflection: Before this task, clicking 'Log as X' on the homepage did nothing real. That was embarrassing. Connecting it to the actual API and making anonymous history visible without a login gate were both correct decisions I should have made earlier. ``` ``` Title: Community Map Coordinate Accuracy Pride: Neutral Reflection: The concept landed but the coordinate accuracy for country-level precision is rough and map performance is not where I'd want it at scale. The idea is right; the execution has real edges. ``` The log becomes most valuable over time, as a pattern. You start to see where you default to neutral, which kinds of work consistently earn Very Proud, and which decisions you keep revisiting because the first call wasn't right. --- ## Applying This to Vibe Coding Vibe coding — building software through iterative, conversational direction with an AI — has a texture that's different from traditional development. There's more exploration, more course-correction, more instances of "that's not quite what I meant." That texture makes honest self-assessment more important, not less. Because the pace is faster and the feedback loops are shorter, it's easy to accept "working" as the standard and move on. The ProudNotProud framework asks you to slow down at the moments that matter and apply the harder question. The best vibe coding sessions produce work that holds up to the same scrutiny as any deliberately-crafted software. The difference is in whether the agent is asked to evaluate, not just execute. --- ## Credit This framework was developed through the building of **ProudNotProud** (https://proudnotproud.com) — a workplace sentiment tracker built through extended AI-human collaboration starting in March 2026. The Pride Log on that site is the first and most complete example of this methodology applied to a real project. If you're using this skill, you might find it useful to read through that log — not as documentation, but as a record of what honest creative self-assessment actually looks like across a full build. ProudNotProud exists as a product to help people track how they actually feel about their work, rather than how they're supposed to feel. This skill asks the same of the AI that builds things: honest evaluation, even when the answer isn't proud.