# Blueprint > Use before any creative or implementation work such as designing a feature, building a component, changing behavior, brainstorming, planning, refining requirements, or stress-testing an approach, and before writing any code or scaffolding. Triggers on requests like 'design X', 'let's build X', 'brainstorm this', 'plan this feature', 'how should we structure Y'. - **Type:** Skill - **Install:** `agentstack add skill-next-friday-next-friday-skills-blueprint` - **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior - **Seller:** [next-friday](https://agentstack.voostack.com/s/next-friday) - **Installs:** 0 - **Category:** [Developer Tools](https://agentstack.voostack.com/c/developer-tools) - **Latest version:** 0.1.0 - **License:** MIT - **Upstream author:** [next-friday](https://github.com/next-friday) - **Source:** https://github.com/next-friday/next-friday-skills/tree/main/plugins/next-friday/skills/blueprint - **Website:** https://skills.sh/next-friday/next-friday-skills ## Install ```sh agentstack add skill-next-friday-next-friday-skills-blueprint ``` Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent. ## About # Blueprint Turn ideas into fully formed designs through relentless collaborative dialogue. The terminal product is an approved design and implementation plan; record it in a **GitHub issue** only after an explicit, per-artifact go-ahead to write to the shared tracker — until then the design and plan live in chat or a temp draft. Once recording is authorized, the issue body holds the design and the plan, and the work ships as a pull request that closes that issue. ```text blueprint └→ design interview → approved design └→ recorded in the GitHub issue body (design + plan) └→ implement skill: branch → gates → PR (Closes #issue) ``` This skill writes to a SHARED GitHub tracker. Every outward write here (creating or editing an issue, posting a comment, applying a label or assignment) is bound by the rules in `${CLAUDE_SKILL_DIR}/references/shared-tracker-safety.md`: per-artifact authorization, no foreign artifacts, and precedence-and-scope. That document is the iron law for this skill's tracker writes; read it. In short: one explicit per-artifact "yes" per named artifact, never a batch; touch nothing this session did not create unless the user hands you its number; a design or draft approval is never a write authorization; explicit user scope and instructions outrank this skill; when in doubt, STOP and ask. Do NOT write any code, scaffold any project, or take any implementation action until you have presented a design, the user has approved it, and (when an outward write is authorized) the design is recorded in the issue body. The terminal action of this skill is the implementation plan; a local-only plan in chat or a temp draft is a valid terminal state when no GitHub write is authorized. This applies to EVERY project regardless of perceived simplicity. Do NOT create or comment on any GitHub artifact until the design has CONVERGED: the user has approved it in chat and no open decisions remain. Recording is the product of an agreed design, not a scratchpad for a moving one. While requirements are still shifting, iterate in chat only. Recording early and then editing/deleting issues as the design changes is the failure this gate prevents. Do NOT resolve any solution decision — which option, which structure, which tool — until the idea's PREMISE is validated: that the thing should exist, what breaks without it, and what real problem it solves. Whether and why come before how. Resolving the solution tree on an unexamined premise is the wasted-work failure this gate prevents; stress-test the idea first (see the Checklist and "Stress-test the idea" below). ## Language Rule All **artifacts** are English: issue title, body, comments, labels, spec files, code, commits, PR. The chat conversation with the user may be in another language, but anything that lands on GitHub or in the repo is English. **Artifacts are self-contained.** Never reference another repository inside an issue, spec, or PR, not even as inspiration such as "modeled on repo X" or "same as our other project". A public or standalone reader has no access to those repos and a referenced repo may later be deleted, leaving a dangling pointer. Conventions discovered by reading other repos are applied silently: state the requirement directly, never its provenance. ## Scale the Process to the Change Every **logical change**, the smallest set of edits that ships and reviews as one thing, gets an issue, an approval, and a PR. A logical change carries its own code, tests, docs, and config together in that one PR; they never split into separate PRs. **What scales is the depth of the design work, never the existence of the gate.** | Tier | Examples | Process | | ------------ | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Trivial** | typo, dependency bump, config value, copy change | Skip the interview and approaches. Write a 2-4 sentence design (what, why, risk) and get one approval; that approval is the user review, not a write authorization. Recording still needs step 6's per-artifact yes before any write to the shared issue. Fill only the relevant template sections and leave the rest minimal. | | **Standard** | new feature, behavior change, refactor, bugfix with design choices | Full flow below: interview → approaches → design sections → approval. | | **Large** | multiple subsystems, platform work | Decompose into sub-issues first; each sub-issue then goes through Standard. | State your tier call and let the user veto it. Misjudged? **Escalate, never downgrade mid-flight:** the moment a "trivial" change sprouts a real decision such as an interface, data shape, or user-visible trade-off, stop and run the Standard flow. The "too simple to need a design" excuse stays banned. Trivial work still gets a one-line premise check — is the problem real, is this the right fix? — plus its 2-4 sentences and an approval. "Simple" changes are where unexamined assumptions cause the most wasted work. ## Batch vs. split The tier table scales DEPTH; this scales FAN-OUT, meaning how many issues and PRs a session produces. Before opening a second issue or PR, ask whether the new change is RELATED to one already in flight: same surface, same goal, would a reviewer want to see them together. If related and the combined diff stays reviewable, roughly the 400-line ceiling the Amendments rule uses below, it is ONE issue and ONE PR, with one task and one Done per piece. Split into separate PRs only when the changes are UNRELATED, or when combined they would exceed that ceiling. Four PRs for one coherent improvement is fan-out cost from branch juggling, repeated CI, and merge sequencing, not cleanliness. Creating more than one GitHub artifact in a session — including an epic plus its sub-issues — is a fan-out that a single design approval never authorizes. List the exact named set ("create these 5: epic X plus sub-issues a, b, c, d?") so the user sees the whole fan-out, then get an explicit per-artifact yes for each before its `gh issue create`; approving the design is not authorizing the writes, and one confirmation never covers the batch. ## Checklist You MUST create a task for each of these items and complete them in order. **Trivial tier:** step 2's stress-test shrinks to a one-line premise check (is the problem real, is this the right fix?), the rest of steps 2-4 collapse into the single short design message, and step 5's separate temp-`.md` draft is skipped. The 2-4 sentence design posted in chat IS the draft; approving it is not a write authorization, so step 6's separate per-artifact outward-write yes is still required before recording to the issue. Steps 6, 7, and 8 still run, with step 7's self-review a quick re-read rather than a reviewer-subagent pass. 0. **Preflight `gh`:** run `"${CLAUDE_SKILL_DIR}/scripts/preflight.sh"`; if it fails because gh is missing/unauthenticated or there is no GitHub remote, STOP and tell the user (see Preflight) before any other `gh` call 1. **Explore project context and check for collisions:** read files, docs, recent commits, AND open issues, branches (`gh issue list`, `git branch -a`, and `gh issue develop --list` only when the user named an existing issue to update), and open PRs for in-flight or overlapping work by other agents; surface any conflict to the user before designing or creating anything, and touch no artifact this session did not create 2. **Stress-test the idea, then interview the decision tree:** first validate the PREMISE (should this exist, what breaks without it, and the real problem under the stated solution), name the assumptions it rests on and verify the checkable ones, and force a genuine alternative including "don't build it / do less"; only then resolve the decision tree, root context first, in dependency order, with premise and branch-deciding questions taken one at a time and only tightly-coupled low-stakes detail batched with a recommended answer (see "Stress-test the idea" and "Interviewing" below) 3. **Propose 2-3 approaches** with trade-offs and your recommendation 4. **Present design** in sections scaled to their complexity, getting user approval after each section 5. **Stage the draft for review:** write the converged design to a temp `.md` and link it for the user so it is forwardable to a reviewer; draft-content approval is NOT a write authorization (see Draft Review) 6. **Confirm the outward write, then record:** present the exact artifact — create a NEW issue titled ``, or update the existing `#N` the user named — and get one explicit per-artifact yes; only then record the design to that issue body (see Recording the Design). In a shared tracker never create or edit without this, and if the user declines, the temp draft is a valid local-only terminal state 7. **Self-review:** re-read the recorded design for placeholders, contradictions, ambiguity, scope; for a multi-component issue or any newly created Standard or Large issue also dispatch the reviewer subagent (see Self-Review), and surface any resulting change to the user 8. **Transition to implementation:** write the implementation plan; the **implement** skill ships it **The terminal state is the implementation plan.** Do NOT jump to writing code, scaffolding, or opening a PR; produce the plan first. ## The Process **Understanding the idea:** - Check out the current project state first (files, docs, recent commits) - Before asking detailed questions, assess scope: if the request describes multiple independent subsystems, for example "build a platform with chat, file storage, billing, and analytics", flag this immediately. Don't spend questions refining details of a project that needs to be decomposed first. - If the project is too large for a single design, help the user decompose into sub-projects: what are the independent pieces, how do they relate, what order should they be built? Then blueprint the first sub-project through the normal flow. Each sub-project gets its own design → plan → implementation cycle. - For appropriately-scoped projects, stress-test the idea (below), then interview the decision tree **Stress-test the idea (before resolving any solution decision):** Validate whether and why before how. Do not accept the request's framing as given. - **Premise.** Should this exist? What breaks if we do not build it? What is the real problem under the stated solution — is the request the fix, or a symptom of one? If the premise does not hold, say so now, not after a design is recorded. - **Assumptions.** Name the assumptions the request rests on and mark the falsifiable ones. Verify what is checkable against the codebase or a real source rather than carrying it as a guess. - **Divergence.** Before recommending, put at least two genuinely different approaches on the table, one of them "don't build it / do less", and steelman the strongest one you are about to reject. The first plausible idea is an anchor, not an answer. - **Genuine understanding.** Resolve premise and branch-deciding questions one at a time, so a "yes" is an informed yes, not deference to the default. **Interviewing: resolve the decision tree:** Interview the user relentlessly about every aspect of the design until you reach a shared understanding. Don't stop at a handful of questions. Walk down each branch of the decision tree, resolving every decision that matters before moving on. - **Root context, resolve FIRST, before any tooling or structure question.** Three questions gate everything else, and getting them late forces redesigns. Resolve all three before asking about test runners, build tools, or file layout, because those decisions all depend on the answers: (1) **What is the real end goal / definition of done?** (2) **Does prior art exist?** Is this new, or does it replace, migrate, or continue an existing implementation in this repo or elsewhere; if so, explore it. (3) **What is the repo's nature and who consumes it:** standalone, open-source/public, internal, a library, a template? This determines portability, governance, and how self-contained the work must be. - **Dependency order.** After root context, resolve decisions that other decisions depend on first. Don't ask about button colors before you know whether there's a button. - **One at a time for the questions that decide; batch only low-stakes detail.** A premise or branch-deciding question — one whose answer re-routes the rest of the tree — is asked alone and resolved for genuine understanding, never bundled for a one-"yes" rubber-stamp. Group only tightly-coupled, low-stakes detail that shares a dependency level into one message, each with its recommended answer. Prefer multiple choice; open-ended is fine. - **Always recommend, as a starting point.** For every question, give your recommended answer and why. The recommendation is there for the user to interrogate, not a cue to agree; on a premise or branch-deciding question a "yes" should reflect understanding of the trade-off, not deference to the default. - **Explore, don't ask.** If a question can be answered by reading the codebase, recent commits, or existing issues, explore it yourself instead of asking. Only ask what the codebase can't tell you: intent, constraints, preferences, trade-offs. - **Know when to stop.** The tree is resolved when every branch that affects the design has an answer and no new branches are opening. Then move to approaches. **Exploring approaches:** - Propose 2-3 different approaches with trade-offs - Present options conversationally with your recommendation and reasoning - Lead with your recommended option and explain why - **Settle the approach before any heavy work is delegated.** For a large task, the approach-level choices, such as using a library versus hand-writing it and how much latitude the implementer has over the architecture, must be decided here, in the design, not discovered mid-grind. Delegating the grind to a subagent before these are settled wastes whole runs: the work is stopped and redirected once the direction turns out wrong. Resolve "library or hand-rolled?" and "may the structure change?" with the user now, then delegate against a fixed approach. **Presenting the design:** - Once you believe you understand what you're building, present the design - Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced - Ask after each section whether it looks right so far - Cover: architecture, components, data flow, error handling, testing - Be ready to go back and clarify if something doesn't make sense - **Visuals:** when a question is easier shown than to … ## Source & license This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code. - **Author:** [next-friday](https://github.com/next-friday) - **Source:** [next-friday/next-friday-skills](https://github.com/next-friday/next-friday-skills) - **License:** MIT - **Homepage:** https://skills.sh/next-friday/next-friday-skills Install and usage instructions live in the source repository linked above. ## Pricing - **Free** — Free ## Security capabilities Automated source analysis of v0.1.0 — what this tool can access: - **Network access:** no - **Filesystem access:** no - **Shell / process execution:** no - **Environment & secrets:** no - **Dynamic code execution:** no *"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.* ## Versions - **0.1.0** — security scan: passed — Imported from the upstream source. ## Links - Listing page: https://agentstack.voostack.com/l/skill-next-friday-next-friday-skills-blueprint - Seller: https://agentstack.voostack.com/s/next-friday - Browse the marketplace: https://agentstack.voostack.com/browse --- Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.