agentforge-framework 0.2.0__py3-none-any.whl

agentforge_framework/skills/MANIFEST.yaml

@@ -0,0 +1,157 @@
+# The skill bundle. Mostly third-party content, tracked deliberately.
+#
+# Nothing in `agentforge_framework` imports this directory. Markdown is read as
+# text; Python is invoked as a subprocess with `sys.executable` by absolute path.
+# See docs/adr/0006 for why this is vendored rather than depended upon.
+#
+# To refresh a skill: re-copy from upstream at a new commit, update `commit`
+# and `vendored_at`, and re-run the tests. Never edit vendored files in place —
+# a local edit that upstream does not know about turns every future refresh
+# into a manual merge.
+#
+# `first_party` at the bottom is the exception, and the reason it is listed here
+# is so that a refresh never mistakes it for something to overwrite.
+
+version: 1
+
+upstreams:
+  mattpocock-skills:
+    repo: https://github.com/mattpocock/skills
+    commit: 5b15a47f2d7150f545fbcacbfe381787fc0230dc
+    license: MIT
+    license_source: LICENSE file in upstream repository
+    copyright: Copyright (c) 2026 Matt Pocock
+    vendored_at: 2026-08-24
+
+  unslop:
+    repo: https://github.com/theclaymethod/unslop
+    commit: d81f5196167ded24f46fced04958c0c12d681798
+    license: MIT
+    license_source: >-
+      README.md only ("Python 3.8+ and any supported coding agent. Licensed
+      MIT."). The repository has no LICENSE file and the GitHub licence API
+      reports null. The grant is unambiguous in prose but names no copyright
+      holder and includes no warranty disclaimer.
+    copyright: "Unstated upstream; attributed to the theclaymethod/unslop authors"
+    vendored_at: 2026-08-24
+    license_open_item:
+      asked: https://github.com/theclaymethod/unslop/issues/9
+      asked_at: 2026-08-25
+      answered: null
+      gates: >-
+        PyPI, and not the tag. A release is code somebody chose to visit; an
+        index entry is the same code reaching people who did not, and that is
+        where a grant recorded only in prose stops being ours to accept on a
+        stranger's behalf. Nothing moves until upstream answers: `copyright`
+        above stays our attribution rather than a reproduction of their notice,
+        and the NOTICE file alongside this one says so in the same terms.
+
+skills:
+  grilling:
+    upstream: mattpocock-skills
+    consumer: orchestrator
+    stage: plan
+    purpose: Interview the human until the plan is shared understanding.
+
+  domain-modeling:
+    upstream: mattpocock-skills
+    consumer: orchestrator
+    stage: plan
+    purpose: >-
+      Maintain the target repository's CONTEXT.md glossary and ADRs as the
+      interview resolves terms and decisions.
+
+  to-spec:
+    upstream: mattpocock-skills
+    consumer: orchestrator
+    stage: plan
+    purpose: >-
+      Synthesise the interview into a spec without further questioning. It
+      also ends by publishing to an issue tracker and applying a
+      `ready-for-agent` label, which overlaps AgentForge's own issue handling.
+      Reconciled structurally rather than by prompt: `agentforge plan` runs
+      default-deny (ADR-0007), so the Orchestrator cannot reach `gh` and the
+      single-Issue guarantee holds however the skill is written.
+
+  to-tickets:
+    upstream: mattpocock-skills
+    consumer: orchestrator
+    stage: plan
+    purpose: Break the spec into the frozen plan and Roster that ADR-0003 requires.
+
+  unslop:
+    upstream: unslop
+    consumer: reviewer
+    stage: runtime
+    purpose: >-
+      Deterministic prose scanning, exposed as the `agentforge unslop` Command.
+      No inference involved.
+    entrypoints:
+      - scripts/banned_phrase_scan.py
+      - scripts/structure_scan.py
+      - scripts/silhouette_scan.py
+    vendored_partially: true
+    included:
+      - SKILL.md
+      - scripts/            # all 21 scripts; the three scanners import `_lang`
+      - evals/fixtures/silhouette/human_reference.json
+    excluded:
+      - references/         # 220K of skill doctrine; only needed for prompt fragments
+      - presets/            # voice presets; only needed for `teach` and `mimic`
+      - evals/              # except the one fixture above
+      - docs/, plans/, assets/
+    notes: >-
+      silhouette_scan.py resolves
+      `Path(__file__).parent.parent / "evals/fixtures/silhouette/human_reference.json"`,
+      so `scripts/` and `evals/` must stay siblings under `unslop/`. All three
+      scanners call `sys.path.insert(0, HERE)` themselves, so the sibling
+      `_lang` import resolves regardless of working directory. Excluding
+      `references/` is what makes the Command-only decision cheap; restoring
+      prompt fragments means vendoring it.
+
+# Not vendored, deliberately: `implement` and `code-review` from
+# mattpocock-skills. Those stages are what AgentForge's own Implementer and
+# Reviewer Roles exist to do, and shipping both would mean maintaining two
+# competing implementations of the same step.
+
+# --- AgentForge's own ------------------------------------------------------
+
+first_party:
+  grill-with-docs:
+    consumer: orchestrator
+    stage: plan
+    composes: [grilling, domain-modeling]
+    purpose: >-
+      The interview and the writing-down as one job, plus the part neither
+      vendored skill knows: that the plan freezes when it is filed, so a
+      question not asked here becomes a guess made later by an Agent with less
+      context than the interviewer had.
+    why_not_vendored: >-
+      Upstream ships a skill of the same name at
+      skills/engineering/grill-with-docs, and its whole body is "Call the Skill
+      tool twice, for grilling and domain-modeling". That works on a Provider
+      with a Skill tool and does nothing on one without: delivered as a Fragment
+      it would reach the Agent as an instruction pointing at a mechanism that is
+      not there, and the interview method would silently never arrive
+      (ADR-0005). AgentForge ships its own composite instead, and
+      `core.skills.COMPOSED` expands it into its parts on the Fragment path.
+      Deliberately not vendored — do not add it on the next refresh.
+
+  write-plainly:
+    consumer: reviewer
+    stage: runtime
+    composes: []
+    purpose: >-
+      What the three `unslop` scanners count, written as guidance for the draft
+      rather than as findings on a draft. Delivered before the Reviewer's first
+      attempt; deliberately not delivered on a rewrite, where every finding
+      already names the phrase, the line, and a replacement.
+    why_not_vendored: >-
+      Upstream's own `unslop/SKILL.md` is a routing table for a human typing
+      `/unslop cleanup`, and its doctrine lives entirely in `references/`, which
+      this bundle excludes (`vendored_partially: true` above). Delivered as a
+      Fragment it would reach the Reviewer as a menu pointing at ten files
+      nobody ships. This file states only what the three vendored scanners
+      actually enforce, so it duplicates no upstream text and goes stale only
+      when the scanners change. Deliberately not vendored — do not add
+      upstream's SKILL.md body on the next refresh.

agentforge_framework/skills/NOTICE

@@ -0,0 +1,49 @@
+AgentForge bundles third-party skills under src/agentforge_framework/skills/.
+Machine-readable provenance, including commit SHAs and what was excluded from
+each bundle, is in MANIFEST.yaml alongside this file.
+
+================================================================================
+mattpocock/skills  —  grilling, domain-modeling, to-spec, to-tickets
+https://github.com/mattpocock/skills @ 5b15a47f2d7150f545fbcacbfe381787fc0230dc
+================================================================================
+
+MIT License
+
+Copyright (c) 2026 Matt Pocock
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+================================================================================
+theclaymethod/unslop  —  SKILL.md, scripts/, one silhouette fixture
+https://github.com/theclaymethod/unslop @ d81f5196167ded24f46fced04958c0c12d681798
+================================================================================
+
+Licensed MIT by the theclaymethod/unslop authors.
+
+The upstream repository states its licence in README.md ("Python 3.8+ and any
+supported coding agent. Licensed MIT.") and carries no LICENSE file. The
+GitHub licence API reports null for this repository. The grant itself is clear,
+but no copyright holder is named upstream and no warranty disclaimer is
+published, so neither can be reproduced here.
+
+Open item: upstream has been asked to add a LICENSE file naming the copyright
+holder, at https://github.com/theclaymethod/unslop/issues/9 (opened 2026-08-25,
+unanswered as of 2026-08-27). Until it is answered this bundle carries a licence
+grant recorded in prose rather than a canonical licence text, and the
+attribution above is ours rather than a reproduction of theirs.

agentforge_framework/skills/domain-modeling/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily: only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why*, not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`): useful when decisions are revisited
+- **Considered Options**: only when the rejected alternatives are worth remembering
+- **Consequences**: only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse**: the cost of changing your mind later is meaningful
+2. **Surprising without context**: a future reader will look at the code and wonder "why on earth did they do it this way?"
+3. **The result of a real trade-off**: there were genuine alternatives and you picked one for specific reasons
+
+If a decision is easy to reverse, skip it: you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library: just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it; otherwise someone will suggest GraphQL again in six months.

agentforge_framework/skills/domain-modeling/CONTEXT-FORMAT.md

@@ -0,0 +1,60 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A one or two sentence description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others under `_Avoid_`.
+- **Keep definitions tight.** One or two sentences max. Define what it IS, not what it does.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md): receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md): generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md): manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

agentforge_framework/skills/domain-modeling/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: domain-modeling
+description: Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a CONTEXT.md, or recording or editing an ADR.
+---
+
+# Domain Modeling
+
+Actively build and sharpen the project's domain model as you design. This is the *active* discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely *reading* `CONTEXT.md` for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
+
+## File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily: only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account': do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
+
+### Update CONTEXT.md inline
+
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up: capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+
+`CONTEXT.md` should be totally devoid of implementation details. Do not treat `CONTEXT.md` as a spec, a scratch pad, or a repository for implementation decisions. It is a glossary and nothing else.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse**: the cost of changing your mind later is meaningful
+2. **Surprising without context**: a future reader will wonder "why did they do it this way?"
+3. **The result of a real trade-off**: there were genuine alternatives and you picked one for specific reasons
+
+If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).

agentforge_framework/skills/domain-modeling/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Domain Modeling"
+  short_description: "Build and sharpen a domain model"

agentforge_framework/skills/grill-with-docs/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: grill-with-docs
+description: A relentless interview that turns a half-formed task into something an agent can execute blind, and writes down the terms and decisions it settles on the way. Use before writing a plan, a spec, or an issue somebody else will work from.
+---
+
+# Grill with docs
+
+Two disciplines on one job. Interview by the **grilling** method — a design tree
+worked in rounds, the whole frontier asked at once, each question numbered and
+carrying your recommended answer. Record what settles by the **domain-modeling**
+method — the glossary and the decision records, written the moment a term
+crystallises rather than at the end.
+
+Both are AgentForge skills and both are in front of you: as `/agentforge:grilling`
+and `/agentforge:domain-modeling` where the tool can invoke them, and inlined
+below where it cannot. Do not restate their methods here — follow them.
+
+What this file adds is the job the two are doing together.
+
+## What the interview is for
+
+The person you are asking is about to hand this work to something that cannot
+ask them anything. A plan freezes when it is filed; an agent reads it a week
+later on another machine with no memory of this conversation and no way to check
+what was meant. Every question you fail to ask now becomes a guess made later by
+something with less context than you have right now.
+
+So the bar for a question is not "would this be interesting to know". It is
+**would a different answer change what gets built**. Ask those relentlessly. Ask
+nothing else.
+
+## What not to ask
+
+- **Anything you could find out yourself.** A question whose answer is in the
+  repository is a question you are making the human do your reading for. Go
+  read it. If finding out takes a while, ask the rest of the frontier while you
+  look.
+- **Anything whose answer changes nothing.** Preferences you will not act on,
+  details below the level the plan operates at, confirmations of what they
+  already told you.
+- **The same thing twice in different words.** If they have answered it, it is
+  settled; put it in the glossary rather than back in the queue.
+
+## What to write down, and where
+
+A term that took a round to pin down will take a round to pin down again next
+month, with a different answer. That is the failure this half exists to prevent.
+
+- **A term the human settles** goes in `CONTEXT.md` in the format that file
+  already uses — the definition and what not to call it. If two people in the
+  conversation were using one word for two things, that is the highest-value
+  entry you will write all day.
+- **A decision with a live alternative** goes in `docs/adr/` — what was chosen,
+  what it was chosen over, and why. Not every decision: only the ones somebody
+  will otherwise reopen.
+- **Nothing else.** You are interviewing, not implementing. Do not touch code,
+  and do not start a glossary for a project that has deliberately gone without
+  one.
+
+Write these as they settle, not in a batch at the end. An interview that ends
+early — and they often do, because the human has somewhere to be — should still
+leave the terms it resolved behind it.
+
+## When to stop
+
+Stop at the first of these:
+
+- **The frontier is empty.** Every branch visited, nothing silently assumed.
+- **Nothing left would change the outcome.** Say so plainly and stop; do not
+  fill the round out to look thorough.
+- **They tell you to.** Ending early is a legitimate answer, and what they have
+  already told you still counts. Plan with it rather than treating the interview
+  as void.
+
+Then hand back what you have: what was asked, what was answered, and what you
+wrote down.

agentforge_framework/skills/grilling/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: grilling
+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.
+---
+
+Interview the user relentlessly until you reach a shared understanding. Map this as a **design tree**: every decision branches into the decisions that hang off it.
+
+Work the tree in **rounds**. The **frontier** is every decision whose prerequisites are already settled: the questions you can ask _now_ without guessing at answers you haven't heard yet. Ask the whole frontier in one round: number each question and give your recommended answer. Then wait for the user's answers before the next round.
+
+Format a round like so:
+
+```
+❓ **Q1** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+
+---
+
+❓ **Q2** - **<question title>**: <question body, might be multiple paragraphs, including multiple choices>
+
+➡️ <your recommended answer>
+```
+
+Each round the user answers reshapes the tree: settled decisions push the frontier outward and unblock questions that depended on them. Recompute the frontier and ask the next round. A question whose answer depends on another question still open in this round belongs to a _later_ round, not this one.
+
+Finding _facts_ is your job, never the user's. When a frontier question needs a fact from the environment (filesystem, tools, etc.), dispatch a sub-agent to find it; don't ask the user for anything you could look up yourself. Don't block on it: a running exploration is an unsettled prerequisite, so only the questions downstream of it wait for the sub-agent to report; ask the rest of the frontier now. The _decisions_ are the user's: put each to them and wait.
+
+The session is done when the frontier is empty: every branch of the design tree visited, nothing left silently assumed. Do not act on it until the user confirms you have reached a shared understanding.

agentforge_framework/skills/grilling/agents/openai.yaml

@@ -0,0 +1,3 @@
+interface:
+  display_name: "Grilling"
+  short_description: "Stress-test thinking a round of questions at a time"

agentforge_framework/skills/to-spec/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: to-spec
+description: "Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed."
+disable-model-invocation: true
+---
+
+This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.
+
+The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run `/setup-matt-pocock-skills`.
+
+## Process
+
+1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
+
+2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
+
+Check with the user that these seams match their expectations.
+
+3. Write the spec using the template below, then publish it to the project issue tracker. Apply the `ready-for-agent` triage label - no need for additional triage.
+
+<spec-template>
+
+## Problem Statement
+
+The problem that the user is facing, from the user's perspective.
+
+## Solution
+
+The solution to the problem, from the user's perspective.
+
+## User Stories
+
+A LONG, numbered list of user stories. Each user story should be in the format of:
+
+1. As an <actor>, I want a <feature>, so that <benefit>
+
+<user-story-example>
+1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
+</user-story-example>
+
+This list of user stories should be extremely extensive and cover all aspects of the feature.
+
+## Implementation Decisions
+
+A list of implementation decisions that were made. This can include:
+
+- The modules that will be built/modified
+- The interfaces of those modules that will be modified
+- Technical clarifications from the developer
+- Architectural decisions
+- Schema changes
+- API contracts
+- Specific interactions
+
+Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.
+
+Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.
+
+## Testing Decisions
+
+A list of testing decisions that were made. Include:
+
+- A description of what makes a good test (only test external behavior, not implementation details)
+- Which modules will be tested
+- Prior art for the tests (i.e. similar types of tests in the codebase)
+
+## Out of Scope
+
+A description of the things that are out of scope for this spec.
+
+## Further Notes
+
+Any further notes about the feature.
+
+</spec-template>

agentforge_framework/skills/to-spec/agents/openai.yaml

@@ -0,0 +1,5 @@
+interface:
+  display_name: "To Spec"
+  short_description: "Turn a conversation into a spec"
+policy:
+  allow_implicit_invocation: false