blueprint-os 1.0.2 → 1.1.0

package/.agent/skills/brainstorming/SKILL.md

@@ -1,157 +1,157 @@
----
-name: brainstorming
-description: Explores a problem through Socratic questioning before any spec or code is written. Surfaces real needs, compares approaches, and produces a design document. Use when the user wants to think through a new product, a new feature, a technical decision, or anything where the right approach is still undecided.
----
-
-# Brainstorming
-
-## When to use this skill
-
-- User says "I want to build X" but hasn't decided how yet
-- Starting a brand new product with no codebase yet
-- Adding a significant feature to an existing codebase
-- A technical or architectural decision needs exploration before committing
-- The approach is unclear or multiple valid paths exist
-- User asks to "brainstorm", "think through", "explore", or "figure out" something
-
-## Workflow
-
-- [ ] Identify which mode applies (see Instructions > Modes)
-- [ ] Load relevant context for the mode (standards, existing files, or nothing)
-- [ ] Ask the brainstorming questions — one section at a time, conversationally
-- [ ] Present 2–3 alternative approaches with tradeoffs after gathering answers
-- [ ] Validate the preferred direction with the user
-- [ ] Save the design document to `specs/brainstorm-<name>.md`
-- [ ] Hand off to `shaping-specs` with the design document as input
-
-## Instructions
-
-### Modes
-
-Pick the mode based on what the user is starting from:
-
-**Mode 1 — New product**
-No codebase exists yet. Start with open-ended exploration. No standards to load. Focus on the problem, the user, and the product vision before any technical decisions.
-
-**Mode 2 — New feature in a legacy codebase**
-A codebase exists. Load `standards/` files first to understand existing patterns and constraints. Brainstorm within those constraints — what fits the existing architecture, what would require deviation and why.
-
-**Mode 3 — New feature with loaded context**
-The user has specific files or modules in mind. Load those files before brainstorming. Keep exploration scoped to the relevant area.
-
-### Brainstorming questions
-
-Ask these in a natural, conversational flow — one section at a time. Do not ask all at once. Wait for responses before moving on.
-
-**1. What is the real problem?**
-- What are you actually trying to solve? (not the solution — the problem)
-- Who experiences this problem and when?
-- What happens today without this? What's the workaround?
-
-**2. What does success look like?**
-- If this works perfectly, what changes for the user?
-- How would you know it worked? What's measurable?
-- What would make this a failure even if it ships?
-
-**3. What are the constraints?**
-- Are there technical boundaries (existing stack, performance, compatibility)?
-- Are there product constraints (scope, timeline, dependencies)?
-- What can we NOT change, no matter what?
-
-**4. What approaches could work?**
-- What's the most obvious solution? What are its downsides?
-- Is there a simpler version that solves 80% of the problem?
-- Is there an existing tool, library, or pattern that does this?
-
-**5. What are the risks?**
-- What could go wrong during implementation?
-- What edge cases will be hardest to handle?
-- What assumption, if wrong, would invalidate the whole approach?
-
-### Presenting alternatives
-
-After gathering answers, present 2–3 distinct approaches:
-
-```
-## Approach A: [Name]
-[One paragraph description]
-
-Pros:
-- [Pro 1]
-- [Pro 2]
-
-Cons:
-- [Con 1]
-- [Con 2]
-
-Best if: [condition where this wins]
-
----
-
-## Approach B: [Name]
-...
-```
-
-Ask the user which direction resonates before writing the design document.
-
-### Design document format
-
-Save to `specs/brainstorm-<name>.md`:
-
-```markdown
-# Brainstorm: [Topic]
-
-**Date:** [YYYY-MM-DD]
-**Mode:** New product | Legacy codebase | Feature in context
-**Chosen approach:** [Approach name]
-
-## The problem
-[What we're actually solving and for whom]
-
-## Success criteria
-- [What done looks like]
-
-## Constraints
-- [Technical and product constraints]
-
-## Approaches considered
-### [Approach A]
-[Summary + why it was not chosen, or why it was chosen]
-
-### [Approach B]
-[Summary + tradeoffs]
-
-## Chosen direction
-[Rationale for the selected approach]
-
-## Open questions
-- [Anything still unresolved that shaping-specs needs to address]
-
-## Context loaded
-- `standards/[file].md` — [what was relevant]
-- `path/to/file` — [why it was included]
-```
-
-### Hand-off to shaping-specs
-
-After saving the design document, tell the user:
-
-```
-Brainstorm complete. Load specs/brainstorm-<name>.md and run the shaping-specs skill to formalize this into an implementation spec.
-```
-
-The `shaping-specs` skill will use the design document as its starting context, so the shaping questions can be answered faster and with less ambiguity.
-
-### What to avoid
-
-- Do not propose implementation details during brainstorming — that belongs in the spec
-- Do not skip to a single approach without exploring alternatives
-- Do not skip the problem questions and jump to solutions
-- Do not ask all questions at once — keep the conversation flowing
-
-## Resources
-
-- Design document output: `specs/`
-- Next step: `.agent/skills/shaping-specs/SKILL.md`
-- Existing standards (Mode 2): `standards/README.md`
-- Superpowers brainstorming reference: `npx skills add obra/superpowers`
+---
+name: brainstorming
+description: Explores a problem through Socratic questioning before any spec or code is written. Surfaces real needs, compares approaches, and produces a design document. Use when the user wants to think through a new product, a new feature, a technical decision, or anything where the right approach is still undecided.
+---
+
+# Brainstorming
+
+## When to use this skill
+
+- User says "I want to build X" but hasn't decided how yet
+- Starting a brand new product with no codebase yet
+- Adding a significant feature to an existing codebase
+- A technical or architectural decision needs exploration before committing
+- The approach is unclear or multiple valid paths exist
+- User asks to "brainstorm", "think through", "explore", or "figure out" something
+
+## Workflow
+
+- [ ] Identify which mode applies (see Instructions > Modes)
+- [ ] Load relevant context for the mode (standards, existing files, or nothing)
+- [ ] Ask the brainstorming questions — one section at a time, conversationally
+- [ ] Present 2–3 alternative approaches with tradeoffs after gathering answers
+- [ ] Validate the preferred direction with the user
+- [ ] Save the design document to `specs/brainstorm-<name>.md`
+- [ ] Hand off to `shaping-specs` with the design document as input
+
+## Instructions
+
+### Modes
+
+Pick the mode based on what the user is starting from:
+
+**Mode 1 — New product**
+No codebase exists yet. Start with open-ended exploration. No standards to load. Focus on the problem, the user, and the product vision before any technical decisions.
+
+**Mode 2 — New feature in a legacy codebase**
+A codebase exists. Load `standards/` files first to understand existing patterns and constraints. Brainstorm within those constraints — what fits the existing architecture, what would require deviation and why.
+
+**Mode 3 — New feature with loaded context**
+The user has specific files or modules in mind. Load those files before brainstorming. Keep exploration scoped to the relevant area.
+
+### Brainstorming questions
+
+Ask these in a natural, conversational flow — one section at a time. Do not ask all at once. Wait for responses before moving on.
+
+**1. What is the real problem?**
+- What are you actually trying to solve? (not the solution — the problem)
+- Who experiences this problem and when?
+- What happens today without this? What's the workaround?
+
+**2. What does success look like?**
+- If this works perfectly, what changes for the user?
+- How would you know it worked? What's measurable?
+- What would make this a failure even if it ships?
+
+**3. What are the constraints?**
+- Are there technical boundaries (existing stack, performance, compatibility)?
+- Are there product constraints (scope, timeline, dependencies)?
+- What can we NOT change, no matter what?
+
+**4. What approaches could work?**
+- What's the most obvious solution? What are its downsides?
+- Is there a simpler version that solves 80% of the problem?
+- Is there an existing tool, library, or pattern that does this?
+
+**5. What are the risks?**
+- What could go wrong during implementation?
+- What edge cases will be hardest to handle?
+- What assumption, if wrong, would invalidate the whole approach?
+
+### Presenting alternatives
+
+After gathering answers, present 2–3 distinct approaches:
+
+```
+## Approach A: [Name]
+[One paragraph description]
+
+Pros:
+- [Pro 1]
+- [Pro 2]
+
+Cons:
+- [Con 1]
+- [Con 2]
+
+Best if: [condition where this wins]
+
+---
+
+## Approach B: [Name]
+...
+```
+
+Ask the user which direction resonates before writing the design document.
+
+### Design document format
+
+Save to `specs/brainstorm-<name>.md`:
+
+```markdown
+# Brainstorm: [Topic]
+
+**Date:** [YYYY-MM-DD]
+**Mode:** New product | Legacy codebase | Feature in context
+**Chosen approach:** [Approach name]
+
+## The problem
+[What we're actually solving and for whom]
+
+## Success criteria
+- [What done looks like]
+
+## Constraints
+- [Technical and product constraints]
+
+## Approaches considered
+### [Approach A]
+[Summary + why it was not chosen, or why it was chosen]
+
+### [Approach B]
+[Summary + tradeoffs]
+
+## Chosen direction
+[Rationale for the selected approach]
+
+## Open questions
+- [Anything still unresolved that shaping-specs needs to address]
+
+## Context loaded
+- `standards/[file].md` — [what was relevant]
+- `path/to/file` — [why it was included]
+```
+
+### Hand-off to shaping-specs
+
+After saving the design document, tell the user:
+
+```
+Brainstorm complete. Load specs/brainstorm-<name>.md and run the shaping-specs skill to formalize this into an implementation spec.
+```
+
+The `shaping-specs` skill will use the design document as its starting context, so the shaping questions can be answered faster and with less ambiguity.
+
+### What to avoid
+
+- Do not propose implementation details during brainstorming — that belongs in the spec
+- Do not skip to a single approach without exploring alternatives
+- Do not skip the problem questions and jump to solutions
+- Do not ask all questions at once — keep the conversation flowing
+
+## Resources
+
+- Design document output: `specs/`
+- Next step: `.agent/skills/shaping-specs/SKILL.md`
+- Existing standards (Mode 2): `standards/README.md`
+- Superpowers brainstorming reference: `npx skills add obra/superpowers -a antigravity -y --copy`

package/.agent/skills/creating-skills/SKILL.md

@@ -16,7 +16,7 @@ description: Acquires or creates Blueprint OS skills. Searches skills.sh registr
 
 - [ ] Clarify the skill's purpose — what task does it solve, and what are its triggers?
 - [ ] Search skills.sh for an existing community skill (see Instructions > Discovering on skills.sh)
-- [ ] If found: install with `npx skills add <owner/repo>` and evaluate fit
+- [ ] If found: install with `npx skills add <owner/repo> -a antigravity -y --copy` and evaluate fit
 - [ ] If it covers the need as-is: done — update the Skills Index in `README.md`
 - [ ] If it partially fits: customize it (see Instructions > Customizing an installed skill)
 - [ ] If nothing suitable found: create from scratch (see Instructions > Creating from scratch)
@@ -32,7 +32,7 @@ Before building anything, search the [skills.sh registry](https://skills.sh) —
 **Search via agent:**
 
 ```bash
-npx skills add https://github.com/vercel-labs/skills --skill find-skills
+npx skills add https://github.com/vercel-labs/skills --skill find-skills -a antigravity -y --copy
 ```
 
 Then ask the `find-skills` skill to search for what you need.
@@ -42,18 +42,18 @@ Then ask the `find-skills` skill to search for what you need.
 **Install a skill:**
 
 ```bash
-npx skills add <owner/repo>
+npx skills add <owner/repo> -a antigravity -y --copy
 ```
 
 Example:
 
 ```bash
-npx skills add supabase/agent-skills
-npx skills add vercel-labs/agent-skills
-npx skills add anthropics/skills
+npx skills add supabase/agent-skills -a antigravity -y --copy
+npx skills add vercel-labs/agent-skills -a antigravity -y --copy
+npx skills add anthropics/skills -a antigravity -y --copy
 ```
 
-Installed skills land in `.agent/skills/` automatically — compatible with Blueprint OS out of the box.
+The `-a antigravity` flag installs to `.agent/skills/`, matching Blueprint OS. The `--copy` flag creates real files (not symlinks) so deleting `.agents` won't break the skill when Cursor is detected.
 
 ### Customizing an installed skill
 

package/.agent/skills/deploying-standards/SKILL.md

@@ -1,85 +1,85 @@
----
-name: deploying-standards
-description: Injects relevant project standards into the agent's current context before implementation work begins. Use when the user is about to start coding, asks the agent to build something, or says "inject standards", "load standards", or "deploy standards".
----
-
-# Deploying Standards
-
-## When to use this skill
-
-- User is about to start implementation on a task or feature
-- User asks to "inject standards", "load context", or "deploy standards"
-- Starting a new conversation with context that needs to carry forward
-- After shaping a spec and before executing it
-
-## Workflow
-
-- [ ] Check if a spec exists for the current task in `specs/`
-- [ ] Read `standards/README.md` to see what standards files are available
-- [ ] Read `references/README.md` to see what reference files exist
-- [ ] Identify which standards and references are relevant to the current task (spec may list applicable references)
-- [ ] Read those standards and reference files and internalize the content
-- [ ] Confirm to the user which standards and references were loaded
-- [ ] Proceed with the task using those standards and references actively applied
-
-## Instructions
-
-### Relevance mapping
-
-Match the task type to the standards files most likely to apply:
-
-| Task type | Standards to load |
-|---|---|
-| Building a UI component | `component-patterns`, `naming-conventions`, `tech-stack` |
-| Creating an API endpoint | `api-design`, `error-handling`, `naming-conventions` |
-| Writing database queries | `data-models`, `naming-conventions` |
-| Adding authentication | `authentication`, `error-handling` |
-| Writing tests | `testing-approach`, `naming-conventions` |
-| Refactoring | `naming-conventions`, `folder-structure`, relevant domain |
-| General feature | `tech-stack`, `naming-conventions`, `folder-structure` |
-
-When in doubt, always load `tech-stack` and `naming-conventions` at minimum.
-
-### Auto-suggest mode
-
-If the user says "deploy standards" without specifying which:
-
-1. Ask what they are about to build (one sentence)
-2. Use the relevance map above to select the appropriate files
-3. Load those files and confirm: "Loaded: `standards/api-design.md`, `standards/naming-conventions.md`"
-
-### Manual mode
-
-If the user specifies standards explicitly (e.g., "inject the API standards"):
-
-1. Locate the matching file in `standards/`
-2. Read it and confirm it is loaded
-
-### References
-
-If the spec lists "Applicable references" or the task involves UI flows, architecture, or design, check `references/` and load relevant files (design docs, flowcharts, diagrams). Reference `references/README.md` for the index.
-
-### After loading
-
-State which standards and references were loaded, then proceed with the task. Keep standards active throughout the session — do not ignore them mid-task.
-
-If a decision during execution conflicts with a loaded standard, surface the conflict explicitly:
-
-```
-This would normally follow [standard X], but [situation]. Do you want me to follow the standard or make an exception here?
-```
-
-### Standards not found
-
-If `standards/` is empty or does not exist:
-
-```
-No standards files found. To create standards for this project, use the discovering-standards skill.
-```
-
-## Resources
-
-- Standards directory: `standards/`
-- References directory: `references/`
-- Discover new standards: `.agent/skills/discovering-standards/SKILL.md`
-- Shape a spec first: `.agent/skills/shaping-specs/SKILL.md`
+---
+name: deploying-standards
+description: Injects relevant project standards into the agent's current context before implementation work begins. Use when the user is about to start coding, asks the agent to build something, or says "inject standards", "load standards", or "deploy standards".
+---
+
+# Deploying Standards
+
+## When to use this skill
+
+- User is about to start implementation on a task or feature
+- User asks to "inject standards", "load context", or "deploy standards"
+- Starting a new conversation with context that needs to carry forward
+- After shaping a spec and before executing it
+
+## Workflow
+
+- [ ] Check if a spec exists for the current task in `specs/`
+- [ ] Read `standards/README.md` to see what standards files are available
+- [ ] Read `references/README.md` to see what reference files exist
+- [ ] Identify which standards and references are relevant to the current task (spec may list applicable references)
+- [ ] Read those standards and reference files and internalize the content
+- [ ] Confirm to the user which standards and references were loaded
+- [ ] Proceed with the task using those standards and references actively applied
+
+## Instructions
+
+### Relevance mapping
+
+Match the task type to the standards files most likely to apply:
+
+| Task type | Standards to load |
+|---|---|
+| Building a UI component | `component-patterns`, `naming-conventions`, `tech-stack` |
+| Creating an API endpoint | `api-design`, `error-handling`, `naming-conventions` |
+| Writing database queries | `data-models`, `naming-conventions` |
+| Adding authentication | `authentication`, `error-handling` |
+| Writing tests | `testing-approach`, `naming-conventions` |
+| Refactoring | `naming-conventions`, `folder-structure`, relevant domain |
+| General feature | `tech-stack`, `naming-conventions`, `folder-structure` |
+
+When in doubt, always load `tech-stack` and `naming-conventions` at minimum.
+
+### Auto-suggest mode
+
+If the user says "deploy standards" without specifying which:
+
+1. Ask what they are about to build (one sentence)
+2. Use the relevance map above to select the appropriate files
+3. Load those files and confirm: "Loaded: `standards/api-design.md`, `standards/naming-conventions.md`"
+
+### Manual mode
+
+If the user specifies standards explicitly (e.g., "inject the API standards"):
+
+1. Locate the matching file in `standards/`
+2. Read it and confirm it is loaded
+
+### References
+
+If the spec lists "Applicable references" or the task involves UI flows, architecture, or design, check `references/` and load relevant files (design docs, flowcharts, diagrams). Reference `references/README.md` for the index.
+
+### After loading
+
+State which standards and references were loaded, then proceed with the task. Keep standards active throughout the session — do not ignore them mid-task.
+
+If a decision during execution conflicts with a loaded standard, surface the conflict explicitly:
+
+```
+This would normally follow [standard X], but [situation]. Do you want me to follow the standard or make an exception here?
+```
+
+### Standards not found
+
+If `standards/` is empty or does not exist:
+
+```
+No standards files found. To create standards for this project, use the discovering-standards skill.
+```
+
+## Resources
+
+- Standards directory: `standards/`
+- References directory: `references/`
+- Discover new standards: `.agent/skills/discovering-standards/SKILL.md`
+- Shape a spec first: `.agent/skills/shaping-specs/SKILL.md`