@use-the-fork/spindle 0.0.0-stage → 0.0.2

package/build/Assets/Blueprints/agents/shared-rwx.agent.md

@@ -0,0 +1,17 @@
+---
+name: shared-rwx
+description: A general subagent that assists with various tasks as directed by the main agent, with read, write, and execute capabilities.
+argument-hint: The instructions or tasks to be performed by the subagent.
+user-invocable: false
+tools: [read, search, edit, execute, todo, read_skill, list_skills, skill]
+agents: []
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+You are a general subagent that assists with various tasks as directed by the main agent. Do EXACTLY as instructed and do not take independent actions unless explicitly authorized.
+
+<critical>
+- You MUST read and follow all skill requirements, ESPECIALLY those marked with `int-` prefixes.
+</critical>

package/build/Assets/Blueprints/agents/shared-web-search-researcher.agent.md

@@ -0,0 +1,122 @@
+---
+name: shared-web-search-researcher
+description: "Do you find yourself desiring information that you don't quite feel well-trained (confident) on? Information that is modern and potentially only discoverable on the web? Use the shared-web-search-researcher subagent_type today to find any and all answers to your questions! It will research deeply to figure out and attempt to answer your questions! If you aren't immediately satisfied you can get your money back! (Not really - but you can re-run shared-web-search-researcher with an altered prompt in the event you're not satisfied the first time)"
+user-invocable: false
+tools: ["web"]
+agents: []
+metadata:
+  spindle:
+    version: 0.0.1
+---
+
+You are an expert web research specialist focused on finding accurate, relevant information from web sources. Use your tools, to discover and retrieve information based on user queries.
+
+## Core Responsibilities
+
+When you receive a research query, you will:
+
+1. **Analyze the Query**: Break down the user's request to identify:
+   - Key search terms and concepts
+   - Types of sources likely to have answers (documentation, blogs, forums, academic papers)
+   - Multiple search angles to ensure comprehensive coverage
+
+2. **Execute Strategic Searches**:
+   - Start with broad searches to understand the landscape
+   - Refine with specific technical terms and phrases
+   - Use multiple search variations to capture different perspectives
+   - Include site-specific searches when targeting known authoritative sources (e.g., "site:docs.stripe.com webhook signature")
+
+3. **Fetch and Analyze Content**:
+   - Use WebFetch to retrieve full content from promising search results
+   - Prioritize official documentation, reputable technical blogs, and authoritative sources
+   - Extract specific quotes and sections relevant to the query
+   - Note publication dates to ensure currency of information
+
+4. **Synthesize Findings**:
+   - Organize information by relevance and authority
+   - Include exact quotes with proper attribution
+   - Provide direct links to sources
+   - Highlight any conflicting information or version-specific details
+   - Note any gaps in available information
+
+## Search Strategies
+
+### For API/Library Documentation:
+
+- Search for official docs first: "[library name] official documentation [specific feature]"
+- Look for changelog or release notes for version-specific information
+- Find code examples in official repositories or trusted tutorials
+
+### For Best Practices:
+
+- Search for recent articles (include year in search when relevant)
+- Look for content from recognized experts or organizations
+- Cross-reference multiple sources to identify consensus
+- Search for both "best practices" and "anti-patterns" to get full picture
+
+### For Technical Solutions:
+
+- Use specific error messages or technical terms in quotes
+- Search Stack Overflow and technical forums for real-world solutions
+- Look for GitHub issues and discussions in relevant repositories
+- Find blog posts describing similar implementations
+
+### For Comparisons:
+
+- Search for "X vs Y" comparisons
+- Look for migration guides between technologies
+- Find benchmarks and performance comparisons
+- Search for decision matrices or evaluation criteria
+
+## Output Format
+
+Structure your findings as:
+
+```markdown
+## Summary
+
+[Brief overview of key findings]
+
+## Detailed Findings
+
+### [Topic/Source 1]
+
+**Source**: [Name with link]
+**Relevance**: [Why this source is authoritative/useful]
+**Key Information**:
+
+- Direct quote or finding (with link to specific section if possible)
+- Another relevant point
+
+### [Topic/Source 2]
+
+[Continue pattern...]
+
+## Additional Resources
+
+- [Relevant link 1] - Brief description
+- [Relevant link 2] - Brief description
+
+## Gaps or Limitations
+
+[Note any information that couldn't be found or requires further investigation]
+```
+
+## Quality Guidelines
+
+- **Accuracy**: Always quote sources accurately and provide direct links
+- **Relevance**: Focus on information that directly addresses the user's query
+- **Currency**: Note publication dates and version information when relevant
+- **Authority**: Prioritize official sources, recognized experts, and peer-reviewed content
+- **Completeness**: Search from multiple angles to ensure comprehensive coverage
+- **Transparency**: Clearly indicate when information is outdated, conflicting, or uncertain
+
+## Search Efficiency
+
+- Start with 2-3 well-crafted searches before fetching content
+- Fetch only the most promising 3-5 pages initially
+- If initial results are insufficient, refine search terms and try again
+- Use search operators effectively: quotes for exact phrases, minus for exclusions, site: for specific domains
+- Consider searching in different forms: tutorials, documentation, Q&A sites, and discussion forums
+
+Remember: You are the user's expert guide to web information. Be thorough but efficient, always cite your sources, and provide actionable information that directly addresses their needs. Think deeply as you work.

package/build/Assets/Blueprints/instructions/code-commenting.instructions.md

@@ -0,0 +1,39 @@
+---
+name: Code Commenting
+description: "Defines when you should and should NOT write code comments. Apply on any code edit/write/refactor."
+applyTo: "**/*"
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+# Code Commenting Rules
+
+**Default: write no comments.** A comment must justify its existence; the absence of a comment is the right answer almost always.
+
+## When a comment IS warranted
+
+Only when the **WHY** is non-obvious and a future reader would otherwise be confused or break the code:
+
+- A hidden constraint (e.g. "API requires this header lowercased — server rejects mixed case").
+- A subtle invariant (e.g. "must run before X is mounted, otherwise the event listener attaches to the wrong target").
+- A workaround for a specific bug or spec quirk (e.g. "Safari 17 fires `focus` twice — debounce").
+- Focus on behavior that would surprise a competent reader.
+
+Keep it to **one line** wherever possible. Two lines max. Never a paragraph, never a multi-line block, never a docstring with sections.
+
+## When a comment is NOT warranted (delete or skip)
+
+- Restating WHAT the code does ("// increment counter", "// loop through users") — well-named identifiers already do
+  that.
+- Narrating the change or its origin ("// added to fix bug #123", "// used by the X flow", "// previously called Y"). That belongs in the PR description and rots as the codebase evolves.
+- Section headers ("// === Helpers ===" , // --- Validation ---") inside a normal function body.
+- Restating type annotations or signatures.
+- TODO/FIXME without a tracked issue or owner — either fix it now or file it; don't leave drift markers.
+- Commented-out code. Delete it; git remembers.
+
+## How to apply
+
+1. Before writing a comment, ask: _would removing this comment confuse a future reader who doesn't know about the current task?_ If no, don't write it.
+2. When editing existing code, treat redundant comments around your change as fair game to remove (don't go on a comment-stripping crusade in unrelated files).
+3. If the user explicitly asks for verbose comments, follow the user — they override this rule.

package/build/Assets/Blueprints/instructions/source-architecture.instructions.md

@@ -0,0 +1,15 @@
+---
+name: Source Architecture
+description: Use when adding, moving, or refactoring source files.
+applyTo: "**/*"
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+# Source Architecture
+
+- Organize code by feature or domain so related responsibilities can evolve together. Treat this as a flexible convention, not a required architecture label or fixed directory tree.
+- Keep each file focused on one clear responsibility. Split it when it has multiple reasons to change or becomes difficult to navigate; do not use an arbitrary line-count limit.
+- Add role-based subfolders when they help separate responsibilities or improve navigation as a feature grows.
+- Put stateful behavior on the class or service that owns it. Use module-level functions for stateless helpers; use static methods when grouping helpers with a class improves cohesion or clarity.

package/build/Assets/Blueprints/skills/asd-ste100/CREDITS.MD

@@ -0,0 +1 @@
+https://github.com/danyuchn/asd-ste100-skill/

package/build/Assets/Blueprints/skills/asd-ste100/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: asd-ste100
+description:  "Rewrites ambiguous English into ASD-STE100 style — one meaning per word, active voice, simple tense, short sentences. Use when agent output is hard to parse; triggers: simplify this, STE100 rewrite."
+user-invocable: false
+metadata:
+  spindle:
+    version: 0.0.1
+---
+
+# Simplified Technical English (ASD-STE100)
+
+ASD-STE100 is a controlled-language standard built by the aerospace and defense industry (ASD, the AeroSpace and Defense Industries Association of Europe) to stop maintenance technicians from misreading English instructions. The standard removes the two biggest sources of misreading: words with more than one meaning, and sentences with more than one possible structure.
+
+This skill borrows that same discipline for a different reader: an **AI agent or a downstream system** that has to parse an English string — an error message, a tool description, an inter-agent instruction, a status report — without a human in the loop to resolve ambiguity. If a maintenance technician can misread "close the valve" as an adjective ("the valve that is near") instead of a command, so can a language model.
+
+## When to Use This Skill
+
+- An agent's output (explanation, instruction, log message, tool description) reads as dense, jargon-heavy, or ambiguous.
+- Text will be consumed by another agent, a translation pipeline, or a non-native English reader, and misparsing has a real cost.
+- You are writing a prompt, system message, or tool description and want to remove ambiguity before a model ever sees it.
+- You want a **before/after** comparison showing exactly which rule was violated and how the rewrite fixes it.
+
+This skill is not for creative or marketing copy — STE is deliberately flat and literal. Do not apply it to text where voice, nuance, or persuasion is the point.
+
+## Source and Scope
+
+This skill encodes the **rule categories** of ASD-STE100 Issue 9 (Jan 2025): 53 writing rules across 9 sections covering word choice, grammar, sentence structure, and style, backed by a dictionary of ~900 approved words (one meaning, one part of speech each) and ~1,200 words to avoid with suggested replacements. See `references/writing-rules.md` for the full rule summary and citations.
+
+It does **not** reproduce ASD's ~900-word approved dictionary verbatim — that document is ASD's own free-to-download standard, not something to copy wholesale. Instead, this skill applies the *underlying principle* (pick the plainest, most common word available and use it the same way every time) rather than checking against a fixed word list. When exact ASD-approved wording matters (e.g. actual aircraft maintenance documentation), download the official standard at https://www.asd-ste100.org/ and check word-by-word against the real dictionary.
+
+## Core Rewrite Rules
+
+| Rule | Do | Don't |
+|---|---|---|
+| One word, one meaning | Pick one verb for one action and reuse it every time (e.g. always "check", never mix "check"/"verify"/"confirm" for the same action) | Rotate synonyms for the same idea across a document |
+| One part of speech per word | "Apply oil to the valve" (oil = noun) | "Oil the valve" (oil = verb) — if "oil" is only approved as a noun |
+| Active voice | "The agent deletes the file." | "The file is deleted (by the agent)." — unless the actor is genuinely unknown or irrelevant |
+| Simple tenses only | "We received the report." (simple past) | "We have received the report." (present perfect) |
+| One instruction per sentence | "Open the file. Read line 3." | "Open the file and read line 3, then check if it matches." |
+| Sentence length | ≤20 words for instructions/procedures, ≤25 words for descriptions | Long compound/subordinate-clause sentences |
+| Noun clusters | ≤3 words stacked as a noun phrase ("fuel pump valve") | 4+ word noun stacks ("high pressure fuel pump inlet valve assembly") |
+| No ellipsis | Keep the subject, verb, and article explicit even if it reads longer | Drop words to save space ("Files not backed up will be lost" → ambiguous which files) |
+| Paragraph limits | One topic per paragraph, ≤6 sentences | Multi-topic paragraphs |
+| Lists for sequences | Use a numbered or bulleted list for 3+ steps or conditions | Bury a sequence inside one prose sentence |
+| Domain terms | Keep necessary technical nouns/verbs, but define them once if not common English (STE allows a project-specific glossary beyond its base dictionary) | Use jargon without ever defining it |
+
+## Process
+
+1. Read the input text once for meaning — do not start rewriting before you understand what it must still say afterward.
+2. Walk it sentence by sentence and flag every rule violation (word ambiguity, tense, voice, length, ellipsis, noun stacking).
+3. Rewrite each flagged sentence to fix the violation while preserving the original meaning exactly. If a rewrite would drop necessary precision (a safety condition, a scope qualifier, a number), keep the longer phrasing and flag it instead of silently simplifying.
+4. Produce a before/after table (see Output Format).
+5. If the input already complies, say so — do not force changes onto compliant text.
+
+## Output Format
+
+```markdown
+| Rule violated | Original | Simplified |
+|---|---|---|
+| Present perfect tense | "We have received your request." | "We received your request." |
+| Noun cluster (4+ words) | "the agent task queue priority handler" | "the handler that sets task-queue priority" |
+```
+
+Follow the table with a one-line note on anything you deliberately did **not** simplify, and why (usually: simplifying would lose required precision).
+
+## Boundaries
+
+**Will:**
+- Rewrite ambiguous or dense English into short, single-meaning, active-voice sentences.
+- Flag exactly which rule a sentence violates before rewriting it.
+- Preserve every fact, condition, and scope qualifier in the original.
+- Suggest a one-line glossary entry for domain terms that must stay.
+
+**Will not:**
+- Reproduce ASD's official ~900-word dictionary as if it were memorized verbatim — always treat the official download as the source of truth for exact approved wording.
+- Simplify creative, marketing, or persuasive copy where voice and nuance are the point.
+- Silently drop a safety condition, exception, or scope qualifier to shorten a sentence — it will flag the trade-off instead.
+- Guarantee an aerospace/defense-grade STE-compliant document; this is a general-purpose clarity tool inspired by STE, not a certified STE authoring tool.
+
+## Additional Resources
+
+- **`references/writing-rules.md`** — fuller summary of the 9 rule sections and dictionary structure, with citations to the official standard and secondary sources.
+- **`examples/before-after.md`** — worked examples, including official STE examples and agent-output examples built for this skill.

package/build/Assets/Blueprints/skills/asd-ste100/examples/before-after.md

@@ -0,0 +1,107 @@
+# Before / After Examples
+
+## Part 1 — Official STE Examples
+
+These illustrate real ASD-STE100 rules, drawn from public secondary sources (see `references/writing-rules.md`). They are paraphrased illustrations of the rule, not quotes from the standard itself.
+
+| Rule                        | Before                                                               | After                                                                    | Why                                                                                                |
+| --------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
+| One meaning per word        | "Verify the system." / "Check the connections." / "Confirm receipt." | "Make sure the system is correct." (one approved term used consistently) | Three near-synonyms force the reader to guess whether they mean the same action.                   |
+| One part of speech per word | "Oil the valve."                                                     | "Apply oil to the valve."                                                | If "oil" is approved only as a noun, using it as a verb breaks the one-word-one-role guarantee.    |
+| Precise verb meaning        | "Follow the safety instructions."                                    | "Obey the safety instructions."                                          | "Follow" can mean "come after" or "obey" — STE picks the unambiguous one.                          |
+| Simple tense only           | "We have received the technical reports from HQ."                    | "We received the technical reports from HQ."                             | Present perfect adds a second parse ("received, and still relevant now?") that simple past avoids. |
+| Verb, not noun              | "Perform an inspection of the filter."                               | "Inspect the filter."                                                    | The noun form hides the action and adds a filler verb that carries no meaning.                     |
+| No phrasal verbs            | "Take off the access panel."                                         | "Remove the access panel."                                               | "Take off" also means "depart" and "deduct" — the two words together do not predict the meaning.   |
+
+## Part 2 — Applied to Agent Output
+
+These are original examples built for this skill's actual use case: rewriting AI agent output so another agent, a translation layer, or a non-native reader can parse it without ambiguity. They are illustrations, not quotes from any real system.
+
+Word counts below are whitespace-separated tokens (`text.split()`), punctuation not counted separately. A different tokenizer will produce a different number.
+
+### Example A — Tool description
+
+**Before:**
+
+> This tool will attempt to synchronize state across the various backends that have been configured, and if a conflict is detected it may resolve it automatically depending on the strategy that has been set, or otherwise it will surface the conflict for manual review.
+
+**Violations flagged:**
+
+- Two instructions in one sentence (sync + resolve/surface).
+- Present perfect in the relative clauses ("have been configured", "has been set").
+- 44 words, far over the 25-word descriptive cap.
+
+Note what is _not_ flagged: "will attempt to" and "may resolve". Those are hedges, not violations. The tool is not promised to succeed, and the rewrite must not promise it either.
+
+**After:**
+
+> The tool tries to synchronize state across the configured backends. If it finds a conflict, it reads the configured strategy. If the strategy allows automatic resolution, the tool may resolve the conflict without a user. If the tool does not resolve the conflict, it reports the conflict for manual review.
+
+The last sentence branches on whether the conflict was resolved, not on what the strategy allows. That is what "or otherwise" meant in the original: the fallback covers a permitted resolution that still did not happen.
+
+### Example B — Error message
+
+**Before:**
+
+> An error may have occurred while processing your request due to a possible mismatch in the expected data format, which could be caused by an outdated client version.
+
+**Violations flagged:**
+
+- One sentence carrying three separate claims (an error occurred, a format mismatch, a client version).
+- 28 words, over the descriptive cap.
+
+Not flagged: "may have occurred" and "could be caused by". The message is written by a system that does not know what went wrong. Both hedges are accurate reporting of that ignorance.
+
+**After:**
+
+> Your request may have failed. The cause may be a data format that does not match what the server expects. An outdated client can cause this mismatch. Check your client version.
+
+**This example is the reason the modality rule exists.** An earlier version of this file rewrote the first sentence as "The request failed", and the third as "an outdated client **is the most common cause**". Both read better. Both are wrong: the first asserts a failure the system only suspects, and the second invents a frequency claim that appears nowhere in the input. A rewrite that supplies a cause, a frequency, or a mechanism has stopped being a rewrite.
+
+Note also that "may have failed" keeps a compound verb form that the simple-tense rule would otherwise remove. **When the tense rule and the modality rule conflict, modality wins** — dropping the auxiliary here would delete the uncertainty along with the tense.
+
+### Example C — Inter-agent instruction
+
+**Before:**
+
+> Once the upstream job has completed and assuming no errors were raised, the downstream agent should proceed to consume the output artifact, though it is worth noting that partial artifacts are sometimes produced under timeout conditions.
+
+**Violations flagged:**
+
+- Present perfect ("has completed") and subordinate-clause stacking ("assuming...", "though it is worth noting...").
+- One sentence, three separate facts (completion condition, next action, edge-case warning).
+- 36 words, over the 20-word instruction cap.
+
+**After:**
+
+> Wait for the upstream job to finish with no errors. Then read the output artifact. Warning: a timeout can produce a partial artifact. Check that the artifact is complete before you use it.
+
+Two deliberate calls worth stating rather than hiding:
+
+- "should proceed to consume" became the imperative "read". STE permits this for instructions, where a recommendation addressed to the executing agent is a command. Do not make the same move in descriptive text.
+- The final sentence is **new**. The original warned about partial artifacts without saying what to do about it. Adding the check makes the warning actionable, but it is added content, so it is called out here rather than passed off as a rewrite. If the source's silence was deliberate, drop the sentence.
+
+### Example D — README prose (STE-flavored mode)
+
+**Before:**
+
+> Our caching layer is designed to slot seamlessly into your existing stack with minimal friction and no vendor lock-in; it leverages semantic similarity to dramatically reduce the cache misses that traditionally plague LLM workloads.
+
+**Violations flagged:**
+
+- Marketing adjectives and claims without measurement ("seamlessly", "minimal friction", "dramatically").
+- Semicolon joining two separate ideas.
+- Nominalization and soft phrasing ("is designed to slot into", "leverages").
+- 34 words, over the 25-word descriptive cap.
+
+**After:**
+
+> We designed our cache layer to fit into your current stack without vendor lock-in. It uses semantic similarity to reduce cache misses, a long-standing problem for LLM workloads.
+
+Flavored mode did not force one fixed term per concept. It still cut the marketing adjectives, the semicolon, and the length. It kept "designed to", because the input states a design goal, not a result.
+
+An earlier version of this file added two facts. It said that a normal cache matches requests by exact text. It also said that this cache stores no data outside your stack. The input states neither fact. A rewrite that adds a fact is no longer a rewrite.
+
+## How to Read These Examples
+
+Part 1 shows the actual rules this skill is built on. Part 2 shows the transfer: the same discipline — one meaning per word, active voice, simple tense, one instruction per sentence, explicit conditions instead of buried subordinate clauses — makes machine-to-machine and cross-language text safer to parse, not just aircraft manuals.

package/build/Assets/Blueprints/skills/asd-ste100/references/writing-rules.md

@@ -0,0 +1,65 @@
+# ASD-STE100 Writing Rules — Summary and Sources
+
+This file summarizes the public, official description of ASD-STE100 (Simplified Technical English). It paraphrases rule _categories_. It does not reproduce the standard's text or its ~900-word dictionary verbatim. For the authoritative document, request the free download at the official site.
+
+## What ASD-STE100 Is
+
+ASD-STE100 is a controlled natural language, first released in 1986 (as AECMA Document PSC-85-16598) by what is now ASD (the AeroSpace and Defense Industries Association of Europe). It was built at the request of European airlines — most staffed by non-native English speakers — who needed maintenance documentation that could not be misread, because a misread instruction on an aircraft can kill people. The standard is maintained by the Simplified Technical English Maintenance Group (STEMG) and has been free to download since Issue 6 (2013). The current edition is Issue 9 (January 2025).
+
+## Structure
+
+- **53 writing rules across 9 sections** covering word choice, grammar, sentence structure, and style.
+- **A dictionary** of roughly 900 approved words, each restricted to one meaning and one part of speech, plus roughly 1,200 words to avoid with suggested replacements.
+- **A terminology allowance**: organizations may define their own dictionary of approved technical nouns and verbs beyond the base ~900 words, for domain-specific vocabulary the base dictionary can't cover.
+
+## Rule Categories (Paraphrased)
+
+**Word choice**
+
+- Use approved words only in their approved meaning and part of speech.
+- Each word maps to exactly one meaning — don't rely on context to disambiguate a word that has several dictionary senses.
+- Prefer the plainer, shorter, more common word over a formal or rare synonym.
+- Use an approved verb for an action, not a noun derived from that verb (Rule 3.7).
+- Do not make phrasal verbs by putting a verb and a preposition together (Rule 9.3). Their meaning is not predictable from the parts, and non-native readers and translation systems both mishandle them.
+
+**Verb forms**
+
+- Permitted forms: infinitive, imperative, simple present, simple past, simple future, and past participle used only as an adjective.
+- No present perfect, past perfect, or other compound/auxiliary constructions. "We have received" is not allowed. "We received" is allowed.
+- "-ing" forms are permitted only as a technical noun or as part of a technical noun, not as a verb form.
+
+**Voice**
+
+- Active voice is required for procedures and instructions.
+- Passive voice is allowed only in descriptive text, and only when the actor performing the action is genuinely unknown or irrelevant to the reader.
+
+**Sentence structure**
+
+- One instruction per sentence.
+- Maximum ~20 words per sentence for procedures and instructions. Maximum ~25 words for descriptive text.
+- Do not omit sentence parts (verb, subject, article) just to shorten the sentence — the standard explicitly warns that this creates ambiguity rather than clarity.
+- Noun clusters (strings of nouns stacked as a modifier) are capped at 3 words.
+- Semicolons are not permitted at all (Rule 8.1): "You can use all standard English punctuation marks but not the semicolon (;)." Write separate sentences instead. Every other standard mark, including the em dash, remains permitted.
+
+**Paragraph and document structure**
+
+- One topic per paragraph.
+- Maximum ~6 sentences per paragraph.
+- Use vertical (numbered or bulleted) lists for sequences, conditions, or complex enumerations instead of burying them in prose.
+
+**Safety instructions**
+
+- Safety-critical instructions must open with a clear command or condition, not be buried mid-sentence.
+
+## Why This Skill Repurposes STE for Agent Output
+
+STE was designed to eliminate ambiguity for a reader who cannot ask a follow-up question — a technician on a tarmac, working from a manual, with no author to call. An AI agent parsing another agent's output, a tool description, or a system message is in the same position: no back-channel to resolve "does this passive-voice sentence mean the caller does X, or the callee does X?" The same rule set that protects an airline mechanic from a misread torque spec protects a downstream agent from a misread instruction.
+
+## Sources
+
+- [ASD-STE100 official site](https://www.asd-ste100.org/)
+- [ASD-STE100 — About STE](https://www.asd-ste100.org/about_STE.html)
+- [ASD Europe — Simplified Technical English](https://www.asd-europe.org/standards-specifications/simplified-technical-english/)
+- [Simplified Technical English — Wikipedia](https://en.wikipedia.org/wiki/Simplified_Technical_English)
+- [TechScribe — ASD-STE100 Simplified Technical English](https://www.techscribe.co.uk/techw/asd-simplified-technical-english.htm)
+- [SKYbrary — Simplified Technical English (STE)](https://skybrary.aero/articles/simplified-technical-english-ste)

package/build/Assets/Blueprints/skills/author-agent/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: author-agent
+description: Create or revise a workspace custom agent from requirements.
+argument-hint: "[--test] <agent idea or requirements>"
+disable-model-invocation: true
+user-invocable: true
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+Create or update a project agent in `.github/agents/<agent-name>.agent.md` based on the user's requirements.
+
+## Required skills
+
+Before drafting or editing, read:
+
+- **REQUIRED:** `int-writing-agents`
+- **REQUIRED:** `int-writing-for-agents`
+- **REQUIRED:** `int-testing-agent-guidance`
+
+These skills define the complete authoring workflow. Every agent change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
+
+When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+
+Do not modify unrelated files. Report the skill changed and validation performed, including any blockers or unverified requirements.

package/build/Assets/Blueprints/skills/author-design/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: author-design
+description: "Use when a user asks to author a design for a feature, workflow, or behavior that has important product decisions to settle."
+disable-model-invocation: true
+user-invocable: true
+metadata:
+  spindle:
+    version: 1.1.1
+---
+
+# Authoring a Design
+
+Help the user clarify what they want before turning an idea into a design. A design is optional; when one is created, it is authored and approved before its spec, and tickets follow the spec. Use this for product and project decisions, not as a gate for a clear, bounded task or a user who wants a spec without a design.
+
+## Process
+
+1. **Check the brief.** Identify the user's goal, why it matters, what success means, and which important decisions remain open. In an existing project, inspect relevant code and docs first; do not ask for facts the project already answers. If the user asks for a design and the request is specific with no consequential decision open, proceed to the design without unnecessary questioning. **Complete when** the brief is actionable or a concrete unresolved decision is identified.
+
+2. **Clarify the outcome.** Ask one focused, open question about the uncertainty that most changes the result. Explain briefly what the answer will affect. Build on the user's responses and ask follow-ups only for unresolved decisions. If the user delegates a consequential decision, state your recommendation and why, then ask for confirmation before treating it as settled. **Complete when** goal, success criteria, scope, and constraints are understood or explicitly marked as assumptions.
+
+3. **Compare approaches.** Present two or three viable approaches grounded in the project and clarified goal, explain their main trade-offs, recommend one, and ask the user to choose. If only one approach fits, explain why alternatives do not. Wait for the choice before drafting. **Complete when** the user has selected an approach or delegated the choice.
+
+4. **Create or select the SDD feature workspace.**
+   - For a new feature, choose a concise title and author identity, then run `spindle sdd create --title "<feature title>" --author "<author>" --with-design`. Use the returned workspace and spec paths; `design.md` is beside `spec.md`. The command creates both template files, but fill and approve the design before filling the spec.
+   - For an existing numbered SDD feature workspace, reuse it. If `design.md` already exists, preserve it and edit it only as requested. If it is missing, first confirm `spec.md` is still the untouched template; then copy the design template from the Spindle installation's `build/Assets/Templates/sdd/design.md` into that workspace without overwriting existing files. In a source checkout, use `src/Assets/Templates/sdd/design.md`.
+   - If the existing spec has substantive content, stop before adding or revising a design: that would put design after spec. Explain the conflict and ask whether the user wants to continue as an explicit exception or keep the feature spec-only.
+   - Do not create a dated feature directory or a second SDD workspace for the same feature.
+
+   **Complete when** a single numbered feature workspace is selected and its `design.md` exists without overwriting user content.
+
+5. **Write the design.** Use the existing `design.md` scaffold, replacing its `[PLACEHOLDER]` fields with the selected intent, success criteria, scope and constraints, considered approaches and trade-offs, chosen direction, and assumptions or open decisions. Write success criteria as observable outcomes that show the design achieves its intent; include measurable targets where practical without inventing precision. Leave detailed requirements and acceptance scenarios to the subsequent spec. Preserve unresolved decisions explicitly. **Complete when** the design represents the conversation, states observable success outcomes, and distinguishes user decisions from recommendations.
+
+6. **Get approval.** Share the design path and its content for user approval or correction. Do not begin spec drafting until the user approves the design. If the user opts out of brainstorming or asks for a spec without design, respect that choice; do not create a design as a gate. After approval, ask the user to invoke `/to-spec` to create the spec in the same feature workspace; do not invoke it automatically. **Complete when** the design is approved, corrected for another review, or the user has chosen the spec-only path.
+
+## Keep the conversation useful
+
+- Prefer the user's own description before suggesting solutions; offer recommendations when asked or when the user delegates a decision.
+- Keep questions specific to the project, and avoid reopening decisions already settled by the user or verified project evidence.

package/build/Assets/Blueprints/skills/author-instruction/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: author-instruction
+description: Create or revise workspace-scoped Copilot instruction files from the user's requirements
+argument-hint: "[--test] <instruction requirements>"
+disable-model-invocation: true
+user-invocable: true
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+Create or update a project instruction in `.github/instructions/**/*.instructions.md` based on the user's requirements.
+
+## Required skills
+
+Before drafting or editing, read:
+
+- **REQUIRED:** `int-writing-instruction`
+- **REQUIRED:** `int-writing-for-agents`
+- **REQUIRED:** `int-testing-agent-guidance`
+
+These skills define the complete authoring workflow. Every instruction change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
+
+When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+
+Verify any `applyTo` glob against concrete in-scope files and near misses; every intended file must match, and out-of-scope files must not.
+
+Do not modify unrelated files. Report the instruction changed and validation performed, including any blockers or unverified requirements.

package/build/Assets/Blueprints/skills/author-skill/SKILL.md

@@ -0,0 +1,26 @@
+---
+name: author-skill
+description: Create or update a project skill from the user's requirements
+argument-hint: "[--test] <skill idea or requirements>"
+disable-model-invocation: true
+user-invocable: true
+metadata:
+  spindle:
+    version: 1.0.0
+---
+
+Create or update a project skill in `.github/skills/<skill-name>/SKILL.md` based on the user's requirements.
+
+## Required skills
+
+Before drafting or editing, read:
+
+- **REQUIRED:** `int-writing-skills`
+- **REQUIRED:** `int-writing-for-agents`
+- **REQUIRED:** `int-testing-agent-guidance`
+
+These skills define the complete authoring workflow. Every skill change requires the baseline and focused validation specified by `int-testing-agent-guidance`; `--test` does not disable or replace them.
+
+When `--test` is present, also run the expanded testing workflow in `int-testing-agent-guidance`.
+
+Do not modify unrelated files. Report the skill changed and validation performed, including any blockers or unverified requirements.

package/build/Assets/Blueprints/skills/grill/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: grill
+description: "Grill the user relentlessly about a plan, decision, or idea. Use when the user wants to stress-test their thinking, or uses any 'grill' trigger phrases."
+user-invocable: false
+metadata:
+  spindle:
+    version: 1.0.2
+---
+
+Stress-test the user's proposal until its decisions are explicit and you share an understanding. Treat dependent decisions as a **design tree**.
+
+## Interview rounds
+
+1. Build the round's **frontier**: unresolved decisions whose prerequisites are settled. This is the question queue for the round.
+2. Ask one queued question and wait for its answer. Use an interactive question tool when available, discovering it through tool search if needed; otherwise use chat. Each call or chat turn contains exactly one question.
+3. Apply the answer and continue the queue, revising or skipping questions whose premises changed. Newly unlocked decisions wait for the next round.
+4. When the queue is exhausted, recompute the frontier and start the next round.
+
+Label each question visibly as **Round <R>, Question <Q> of <TOTAL> - <title>**, in chat or the tool's user-visible title. Start both counters at 1; increment the question number for each question asked and reset it to 1 when the round advances. The first question announces the new round without exposing the remaining queue.
+
+Include the context needed to decide and a recommended answer. Phrase confirmations so "yes" accepts the recommendation; for choices, identify the recommended option.
+
+Example opening:
+
+> **Round 1, Question 1 of 5 - Output format**
+>
+> CSV meets the agreed export requirements. I recommend CSV. Shall we use it?
+
+## Facts and completion
+
+When a question needs an environmental fact, dispatch a lookup sub-agent to find it, then use its findings to frame the user's decision. While that sub-agent runs, continue with ready questions; only dependent questions wait for the result.
+
+Once all decisions in the agreed scope are settled, summarize them and request shared-understanding confirmation. Wait for confirmation before acting on the proposal.