You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
🏠
Working from home
Bobby Johnson
NotMyself
🏠
Working from home
Agentic engineer. I build systems where AI agents write, test, and ship real code. Chief Problem Solver at NotMyself.IO
With Claude Code: Starting prompt, criticism, rewritten prompt and generated assets.
Yesterday, I posted a prompt that I had worked on for a couple hours requesting feedback. It didn't get much attention.
So I decided to use Claude to give me some feedback on it. This post documents the process I used to get what I wanted by the end of the day. I post it here for others who are looking for successful techniques to adopt or those who are just curious how other people use Claude.
This prompt was collaboratively generated with Claude. I do not have the original prompt used, but I basically told Claude it was an expert prompt engineer and to interview me about a powershell script I wanted to create a prompt to generate.
I then hand edit the prompt to add a bunch of detail that I thought was relevant.
Me: "Would analyzing my actual repo help evaluate if SpecKit is genuinely useful or just a security blanket?"
Claude: "Yes, let me look at the evidence."
Some context: I've been using GitHub's SpecKit for spec-driven development - the idea that you write elaborate specifications, plans, and task breakdowns before coding, and the AI follows them to prevent mistakes. Sounds great, right?
But I had a nagging feeling it was just making me feel productive without actually preventing problems. So I asked Claude to evaluate it using concrete evidence from a real project we built together: a SpecKit updater tool for Claude Code.
Optimize development plans before implementation. Covers TDD-first planning, progressive disclosure, context window preservation, `/dev-docs` format compliance (plan/context/tasks files), breaking features into testable increments, dependency sequencing, risk assessment, architecture alignment with project constraints (no-ORM, multitenancy), estimation strategies, and ensuring plans follow Red-Green-Refactor methodology. Externalizes code samples to quick reference files to preserve context. Integrates with `/dev-docs` and `/dev-docs-update` commands. Use when creating plans, reviewing implementation strategies, optimizing roadmaps, or before starting major features.