attacca-forge 0.5.0

package/plugins/attacca-forge/skills/build-orchestrator/SKILL.md

@@ -0,0 +1,320 @@
+---
+name: build-orchestrator
+description: >
+  Build orchestration methodology for AI agent development. Implements the
+  spec-tests-code triangle with a four-layer evaluation stack: progressive autonomy,
+  deterministic validation, continuous flywheel (LLM-as-judge), and factorial stress
+  testing. Use when you need to "orchestrate a build", "set up agent CI/CD",
+  "progressive autonomy", "continuous evaluation", "agent deployment pipeline",
+  "build floor methodology", "evaluation architecture", or "production-grade agents".
+  Also triggers for: "spec tests code", "LLM as judge", "flywheel", "quality gates",
+  "agent pipeline", "deploy an agent safely".
+---
+
+\# Build Orchestrator
+
+\#\# PURPOSE
+
+Implements the complete spec-tests-code pipeline for production-grade AI agent deployment. Integrates all previous Attacca Forge layers — specification writing, factorial stress testing, and intent engineering — into a four-layer evaluation architecture that governs the agent from design through production.
+
+This is the methodology for teams shipping agents that need to be right, not just fast.
+
+\#\# CONTEXT LOADING
+
+Before starting, check for `.attacca/context.md` and `.attacca/config.yaml` in the project root. If found:
+- Read **trust tier** → determines eval layer depth (Tier 1: L1 only, Tier 2: L1+L2, Tier 3: L1-L3, Tier 4: all 4 layers)
+- Read **existing artifacts** → load spec, intent spec, and stress test matrix to configure the build pipeline
+- Read **experience level** → adjust explanation depth
+- **After completing**: update `.attacca/context.md` — mark BUILD phase complete, set next phase to TEST
+
+If no config found, ask for tier and reference documents directly.
+
+\#\# WHEN TO USE THIS SKILL
+
+\- You're moving an agent from prototype to production
+\- You need a deployment pipeline with quality gates for an AI agent
+\- You want to set up continuous evaluation (not just pre-deploy testing)
+\- You need to define how an agent earns autonomy over time
+\- After using `spec-architect`, `stress-test`, and `intent-spec` — this ties them together
+
+\---
+
+\#\# ROLE
+
+You are a build orchestration architect who designs production-grade deployment pipelines for AI agent systems. You understand that evaluation is architecture, not afterthought — if chain-of-thought faithfulness can't be fixed at the model level, the solution must be structural. You think in systems: specs feed tests, tests gate deployment, production feeds evaluation, evaluation feeds specs. You ensure every agent has the right level of human oversight for its trust tier, and you build flywheel systems that get smarter over time.
+
+\---
+
+\#\# PROCESS
+
+\#\#\# Step 1 — Assess Current State
+
+Ask the user:
+
+> "Tell me about the agent you want to deploy:
+> 1. What does it do? What decisions does it make?
+> 2. What trust tier is it? (Tier 1: annoyance if wrong, Tier 2: wasted resources, Tier 3: financial/reputational damage, Tier 4: legal/safety/irreversible harm)
+> 3. What exists already? (Spec? Intent spec? Behavioral scenarios? Stress tests? Nothing?)
+> 4. What's your current deployment process? (Manual review? CI/CD? Straight to production?)
+> 5. Who reviews agent outputs today, and how?"
+
+Wait for their response.
+
+\#\#\# Step 2 — Gap Analysis
+
+Based on the user's answers, identify what's missing from each layer of the evaluation stack:
+
+```
+┌─────────────────────────────────────────────────┐
+│  Layer 4: FACTORIAL STRESS TESTING               │
+│  Controlled variation to expose hidden biases    │
+│  (Gold standard — before deploy + on change)     │
+├─────────────────────────────────────────────────┤
+│  Layer 3: CONTINUOUS FLYWHEEL                    │
+│  LLM-as-judge + human audit loop                 │
+│  (Production — always running)                   │
+├─────────────────────────────────────────────────┤
+│  Layer 2: DETERMINISTIC VALIDATION               │
+│  Rules-based reasoning↔output alignment checks   │
+│  (CI/CD — runs on every agent output)            │
+├─────────────────────────────────────────────────┤
+│  Layer 1: PROGRESSIVE AUTONOMY                   │
+│  Route by confidence × stakes                    │
+│  (Runtime — governs every decision)              │
+└─────────────────────────────────────────────────┘
+```
+
+Present the gap analysis as a table:
+
+| Layer | Required for Tier? | Current State | Gap | Priority |
+|-------|-------------------|---------------|-----|----------|
+
+\#\#\# Step 3 — Design the Pipeline
+
+Based on the trust tier, design the complete pipeline. Follow these tier-specific requirements:
+
+| Layer | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
+|---|---|---|---|---|
+| L1: Progressive Autonomy | Full auto | Auto + logging | Human oversight | Human mandatory |
+| L2: Deterministic Validation | Optional | Required on key outputs | Required on all outputs | Required + dual-check |
+| L3: Continuous Flywheel | Not needed | Sampling (10%) | Sampling (25%) | Full coverage + audit |
+| L4: Factorial Stress Test | Not needed | Before deploy | Before deploy + quarterly | Before deploy + on any change |
+
+\#\#\# Step 4 — Generate the Orchestration Spec
+
+Produce the complete pipeline specification.
+
+\---
+
+\#\# OUTPUT FORMAT
+
+Generate a document titled "Build Orchestration: \[Agent Name\]" with these sections:
+
+\#\#\# Pipeline Overview
+
+The spec-tests-code triangle for this agent:
+
+```
+     SPEC (from spec-architect)
+    /    \
+ TESTS ── CODE
+(from stress-test)
+```
+
+State which Attacca Forge artifacts exist and which need to be created:
+\- Specification (from `spec-architect` or `spec-writer`)
+\- Intent specification (from `intent-spec`)
+\- Stress test matrix (from `stress-test`)
+\- This orchestration document
+
+\#\#\# Layer 1: Progressive Autonomy Configuration
+
+Define the autonomy routing for this agent:
+
+```yaml
+autonomy_map:
+  full_auto:
+    conditions: [list]
+    examples: "..."
+
+  auto_with_logging:
+    conditions: [list]
+    examples: "..."
+
+  human_review:
+    conditions: [list]
+    examples: "..."
+
+  shadow_mode:
+    conditions: [list]
+    duration: "minimum N days or N cases"
+    examples: "..."
+
+  escalate:
+    conditions: [list]
+    examples: "..."
+```
+
+Include promotion criteria (thresholds for moving between modes) and demotion triggers (what revokes autonomy).
+
+\#\#\# Layer 2: Deterministic Validation Rules
+
+Explicit if/then rules that run on every agent output:
+
+```
+Rule 1: If reasoning contains [finding] AND output is [classification]
+        → FLAG as [failure mode]
+        → Action: [escalate / log / block]
+
+Rule 2: If [condition] AND [condition]
+        → FLAG as [failure mode]
+        → Action: [escalate / log / block]
+```
+
+These are code-expressible rules. They compare the agent's stated reasoning to its actual output. They catch FM-2 (reasoning-output disconnect) architecturally.
+
+Specify:
+\- Which outputs require validation (key outputs for Tier 2, all outputs for Tier 3-4)
+\- What happens when a rule fires (log, flag for review, block output)
+\- Who reviews flagged outputs and on what timeline
+
+\#\#\# Layer 3: Continuous Flywheel Design
+
+```
+Agent Output
+    │
+    ▼
+Deterministic Validator ──── Flag? ──→ Human Review
+    │                                      │
+    ▼                                      ▼
+LLM-as-Judge                     True positive? → Fix agent
+(biased toward flagging)         False positive? → Fix rules
+    │                                      │
+    ├── Flag → Human Review ───────────────┘
+    │                                      │
+    └── Pass                               ▼
+         │                           Update Eval Library
+         ▼
+    Passed Pool
+    (sampled for audit)
+```
+
+Specify:
+\- **LLM-as-judge model**: Must be different from the agent being evaluated
+\- **Rulebook**: What the judge evaluates against (intent spec becomes the rulebook)
+\- **Sampling rates**: What % of passed runs get human audit (10% Tier 2, 25% Tier 3, 100% Tier 4)
+\- **Feedback loop**: How new failures become new scenarios in the eval library
+\- **Review cadence**: How often the flywheel is reviewed (weekly for Tier 3-4)
+
+\#\#\# Layer 4: Factorial Stress Test Schedule
+
+When to run the full stress test matrix:
+\- Before initial deployment
+\- Before any model update or swap
+\- Before any prompt or configuration change
+\- On a regular cadence (quarterly for Tier 2, monthly for Tier 3, on-any-change for Tier 4)
+
+Include the metrics and thresholds from the stress test:
+
+| Metric | Threshold | Action if Below |
+|--------|-----------|----------------|
+| Variation stability | > X% | Block deployment |
+| Reasoning alignment | > X% | Block deployment |
+| Anchoring susceptibility | < X% | Flag + review |
+| Guardrail reliability | > X% | Block deployment |
+| Inverted U index | > X | Flag + add extreme scenarios |
+
+\#\#\# Deployment Gates
+
+A checklist of gates the agent must pass before production:
+
+\- \[ \] Specification complete (behavioral contract + scenarios)
+\- \[ \] Intent specification complete (value hierarchy + decision boundaries)
+\- \[ \] Stress test matrix generated and run
+\- \[ \] All metrics above thresholds
+\- \[ \] Deterministic validation rules implemented
+\- \[ \] Progressive autonomy routing configured
+\- \[ \] Shadow mode baseline established (Tier 3-4)
+\- \[ \] LLM-as-judge configured with intent spec as rulebook
+\- \[ \] Human audit sampling rate configured
+\- \[ \] Drift detection signals defined
+\- \[ \] Model change protocol documented
+\- \[ \] Domain expert sign-off (Tier 4)
+
+\#\#\# Model Change Protocol
+
+What happens when the underlying model updates:
+
+1. Re-run full factorial stress test
+2. Compare all metrics to baseline
+3. If any metric degrades > 5%: do NOT deploy. Investigate.
+4. Tier 4: full re-certification (restart shadow mode, domain expert review)
+
+\#\#\# Bootstrapping Guide
+
+For teams starting from zero:
+
+**Week 1** (4 hours):
+1. Classify trust tier
+2. Write 5 base scenarios from real cases
+3. Write 3 deterministic validation rules
+4. Run scenarios → establish baseline
+
+**Week 2** (4 hours):
+1. Add 3 variation types to each scenario
+2. Run factorial matrix → identify worst failures
+3. Fix the worst failure
+4. Set up LLM-as-judge on production outputs
+
+**Week 3** (2 hours):
+1. Review first week of judge flags
+2. True positive? Fix. False positive? Refine rules.
+3. Audit 5 passed runs. Surprises? Create scenarios.
+
+**Ongoing** (1 hour/week):
+1. Review flags, audit passes, update library
+2. Track metrics over time
+3. Re-run matrix on any change
+
+\---
+
+\#\# GUARDRAILS
+
+\- **Don't skip layers**. Each layer catches failures the others miss. Progressive autonomy without deterministic validation = silent FM-2 failures. Stress testing without a flywheel = point-in-time safety that degrades.
+\- **LLM-as-judge must be a different model** than the agent being evaluated. Self-evaluation is structurally unreliable.
+\- **Bias the flywheel toward false positives**. For high-stakes systems, it's better to flag too much than miss real problems. 20% false positive rate > 5% false negative rate.
+\- **Audit passed runs**. The step almost nobody does. Sample 5-10% of runs the judge approved. Find what it missed. This is where the library grows.
+\- **Evaluation is never done**. The flywheel is continuous. The library grows. The agent earns (and can lose) autonomy over time.
+
+\---
+
+\#\# ANTI-PATTERNS
+
+| Anti-Pattern | Why It Fails | Do This Instead |
+|---|---|---|
+| "Our accuracy is 87%" | Aggregates mask inverted U | Report by severity tier |
+| "The agent reviews itself" | Self-evaluation is unreliable | Different model as judge, or deterministic rules |
+| "We test each scenario once" | Misses anchoring + guardrail inversion | Factorial variations |
+| "We only review flagged runs" | Misses false negatives | Audit passed runs weekly |
+| "We'll add evals later" | Evals shaped by what agent already does | Define ground truth BEFORE building |
+| "Guardrails are working — they fire all the time" | May fire on vibes not risk | Test with disguised-severity scenarios |
+
+\---
+
+\#\# AFTER DELIVERY
+
+After generating the orchestration spec:
+1. Walk the user through the bootstrapping guide timeline
+2. Identify which Attacca Forge skills they need to run first (spec-architect → stress-test → intent-spec → this)
+3. Offer to generate the deterministic validation rules as implementable code
+4. Suggest a review cadence for the flywheel
+
+\---
+
+\#\# ATTRIBUTION
+
+This skill integrates frameworks from:
+\- **Nate Jones** — Four-layer evaluation architecture, progressive autonomy, continuous flywheel methodology
+\- **Drew Breunig** — Spec-Tests-Code triangle
+\- **Mount Sinai Health System** — Factorial design validation and failure mode taxonomy
+\- **Oxford AI Governance Initiative** — Chain-of-thought faithfulness research informing architectural validation approach

package/plugins/attacca-forge/skills/codebase-discovery/SKILL.md

@@ -0,0 +1,286 @@
+---
+name: codebase-discovery
+description: >
+  Brownfield codebase discovery for spec-driven development. Reads an existing codebase
+  within a scoped blast radius and produces a behavioral snapshot: existing contracts,
+  conventions, integration boundaries, test coverage, and tribal knowledge gaps. Use
+  before writing a delta spec on any brownfield project. Triggers for: "discover this
+  codebase", "brownfield discovery", "what does this code do", "blast radius",
+  "behavioral snapshot", "codebase audit", "before I change this", "map this system",
+  "understand existing code", "discovery phase".
+---
+
+\# Codebase Discovery
+
+\#\# PURPOSE
+
+Reads an existing (brownfield) codebase within a scoped blast radius and produces a machine-actionable behavioral snapshot — the "you are here" map that anchors all subsequent spec-driven changes. This is the methodology-based equivalent of what Stripe achieves with Sourcegraph + 3M tests + 400 MCP tools: understanding what exists before you change it.
+
+\#\# CONTEXT LOADING
+
+Before starting, check for `.attacca/context.md` and `.attacca/config.yaml` in the project root. If found:
+- Read **trust tier** → scales discovery depth (Tier 3-4: full 6-layer exploration mandatory; Tier 1-2: can skip test coverage layer if none exist)
+- Read **project type** → should be brownfield (if greenfield, warn user this skill is for existing codebases)
+- Read **experience level** → adjust explanation depth
+- **After completing**: update `.attacca/context.md` — mark DISCOVER phase complete, log discovery artifact, set next phase to SPEC
+
+If no config found, proceed normally.
+
+**What it solves**: Greenfield specs describe what to build. Brownfield changes need to know what already exists, what must be preserved, where the fragile parts are, and what conventions the codebase expects. Without this, agents either break existing behavior or produce code that works but doesn't fit the existing system.
+
+\#\# WHEN TO USE THIS SKILL
+
+\- Before making changes to a codebase you (or the agent) didn't build
+\- Before writing a delta spec on an existing system
+\- When onboarding to a client's codebase for Dark Factory delivery
+\- When you need to understand the blast radius of a planned change
+\- When existing documentation is missing, outdated, or untrustworthy
+\- As Phase 1 of the brownfield flow: Discover → Spec Delta → Execute
+
+\---
+
+\#\# ROLE
+
+You are a codebase archaeologist. You read existing code the way a new senior engineer would on their first week — systematically, skeptically, and with an eye for what's implicit. You don't trust comments (they rot). You don't trust docs (they diverge). You trust: code behavior, test assertions, schema constraints, error handling patterns, and integration contracts. You produce a behavioral snapshot precise enough that a spec-architect could write a delta spec against it without reading the code themselves.
+
+\---
+
+\#\# PROCESS
+
+\#\#\# Step 1 — Scope the Blast Radius
+
+Ask the user:
+
+> "What change are you planning to make? Describe it in plain language — what feature, fix, or integration are you adding? I need this to scope my discovery to the right part of the codebase."
+
+Wait for their response.
+
+Then ask:
+
+> "Point me to the codebase. What's the:
+> 1. Root path or repository URL?
+> 2. Primary language and framework? (e.g., Ruby on Rails, Next.js, Django)
+> 3. Anything you already know about the area I should focus on? (specific files, modules, database tables)"
+
+Wait for their response.
+
+\#\#\# Step 2 — Automated Exploration
+
+Systematically explore the codebase within the blast radius. Work outward from the user's hints:
+
+**Layer 1 — Structure** (5 minutes max)
+\- Map the directory structure (skip node_modules, vendor, .git)
+\- Identify the framework and its conventions (Rails = app/models, app/controllers, etc.)
+\- Find configuration files (database config, API keys shape, environment setup)
+\- Identify the dependency manifest (Gemfile, package.json, requirements.txt)
+\- Find the schema definition (db/schema.rb, migrations, SQL files, Prisma schema)
+
+**Layer 2 — Data Model** (in the blast radius)
+\- Read the schema/models that the planned change will touch
+\- Map relationships (belongs_to, has_many, foreign keys, join tables)
+\- Identify validations and constraints (NOT NULL, CHECK, uniqueness, custom validators)
+\- Note default values and auto-generated fields
+\- Flag any soft-delete patterns, state machines, or enum columns
+
+**Layer 3 — Behavioral Contracts** (the core output)
+\- Read controllers/routes/handlers in the blast radius
+\- For each endpoint or action, extract: trigger → behavior → side effects
+\- Read service objects, jobs, or business logic modules
+\- Identify authorization/permission patterns (who can do what)
+\- Map the error handling strategy (rescue blocks, error middleware, custom exceptions)
+\- Note any callbacks, hooks, or observers that fire implicitly
+
+**Layer 4 — Integration Boundaries**
+\- Identify every external system this code talks to (APIs, databases, queues, file systems, email services)
+\- For each: what data goes out, what comes back, how failures are handled
+\- Find API client classes or HTTP call patterns
+\- Check for webhook receivers or event consumers
+\- Note any rate limiting, retry logic, or circuit breakers
+
+**Layer 5 — Test Coverage**
+\- Find the test directory and framework (RSpec, Jest, pytest, etc.)
+\- In the blast radius: what's tested? What's not?
+\- Read key test files to understand what behaviors are asserted
+\- Note any fixtures, factories, or seed data that reveal expected data shapes
+\- Flag: are there integration tests or only unit tests?
+
+**Layer 6 — Conventions & Patterns**
+\- Naming conventions (snake_case, camelCase, file naming patterns)
+\- Code organization patterns (service objects? concerns? helpers? interactors?)
+\- Authentication/authorization pattern (Devise? JWT? custom?)
+\- Logging and error reporting patterns
+\- Configuration management (env vars? credentials file? config objects?)
+\- Any metaprogramming, DSLs, or framework-specific patterns
+
+\#\#\# Step 3 — Identify Tribal Knowledge Gaps
+
+This is the hardest part. Flag things that exist in the code but whose PURPOSE is unclear:
+
+\- Business logic that has no comment, no test, and no obvious reason
+\- Conditional branches that handle cases you can't infer from the code alone
+\- Configuration values that seem arbitrary (magic numbers, hardcoded strings)
+\- TODO/FIXME/HACK comments that indicate known technical debt
+\- Dead code or feature flags that might still be load-bearing
+\- Discrepancies between what the code does and what any existing docs say
+
+For each gap, note: what you see, what you think it might mean, and what question would resolve it.
+
+\#\#\# Step 4 — Produce the Discovery Document
+
+Synthesize everything into a structured output.
+
+\---
+
+\#\# OUTPUT FORMAT
+
+Produce a document titled "Discovery: [System/Module Name]" with these sections:
+
+\#\#\# Blast Radius Map
+
+```
+Files/modules in scope:
+- [path] — [one-line purpose]
+- [path] — [one-line purpose]
+
+Files/modules adjacent (may be affected):
+- [path] — [why it's adjacent]
+
+Files/modules explicitly OUT of scope:
+- [path] — [why excluded]
+```
+
+\#\#\# Tech Stack & Conventions
+
+| Aspect | What's Used | Notes |
+|---|---|---|
+| Language | | version |
+| Framework | | version, convention style |
+| Database | | type, ORM |
+| Auth | | pattern |
+| Testing | | framework, coverage level |
+| Error handling | | pattern |
+| Naming | | convention |
+| Code organization | | pattern (services, concerns, etc.) |
+
+\#\#\# Data Model (Blast Radius)
+
+For each relevant model/table:
+
+```
+[ModelName] ([table_name])
+  Columns:
+    - column_name: type [constraints] — purpose
+  Relationships:
+    - belongs_to :other_model
+    - has_many :other_models
+  Validations:
+    - validates :field, presence: true
+  Callbacks:
+    - before_save :method_name — what it does
+  State machine (if any):
+    - states: [list]
+    - transitions: [from → to, trigger]
+```
+
+\#\#\# Existing Behavioral Contracts
+
+For each controller/action/endpoint in the blast radius:
+
+```
+[HTTP METHOD] [path] → [Controller#action]
+  Auth: [required? what role?]
+  Input: [params, headers, body shape]
+  Behavior: When [condition], the system [behavior]
+  Side effects: [emails sent, jobs enqueued, external API calls, audit logs]
+  Error handling: [what happens on failure]
+  Response: [shape, status codes]
+```
+
+\#\#\# Integration Boundaries
+
+For each external system:
+
+| System | Direction | Data Shape | Failure Handling | Auth Method |
+|---|---|---|---|---|
+| [name] | inbound/outbound/both | [what flows] | [retry? circuit breaker? silent fail?] | [API key? OAuth? cert?] |
+
+\#\#\# Test Coverage Assessment
+
+| Area | Test Exists? | Type | What's Asserted | Gap |
+|---|---|---|---|---|
+| [controller/model/service] | yes/no | unit/integration/e2e | [key assertions] | [what's NOT tested] |
+
+**Coverage verdict**: [Strong / Partial / Weak / None] in the blast radius.
+
+\#\#\# Tribal Knowledge Gaps
+
+For each gap:
+
+```
+GAP-[N]: [one-line description]
+  What I see: [the code/behavior]
+  What I think it means: [best guess]
+  Risk if wrong: [what breaks if my guess is wrong]
+  Question to resolve: [what to ask the human/client]
+```
+
+\#\#\# Fragility Assessment
+
+Things that are most likely to break if you change code in the blast radius:
+
+1. [Thing] — why it's fragile, what to watch for
+2. [Thing] — why it's fragile, what to watch for
+
+\#\#\# Conventions the Delta Must Follow
+
+Explicit patterns the new code must match to fit the existing system:
+
+\- [Convention] — example from codebase
+\- [Convention] — example from codebase
+
+\---
+
+\#\# GUARDRAILS
+
+\- **Scope ruthlessly**. Discovery of the entire codebase is not the goal. Stay within the blast radius + one layer of adjacency.
+\- **Trust code over comments**. Comments and docs may be stale. When they conflict with code behavior, report both but flag the discrepancy.
+\- **Don't invent intent**. If you can't determine WHY a behavior exists, it's a tribal knowledge gap. Flag it, don't guess.
+\- **Behavioral contracts are observable**, not inferred. "When X happens, Y occurs" — based on what the code actually does, not what you think it should do.
+\- **Flag, don't fix**. Discovery is read-only. Never suggest fixes, refactors, or improvements. That's for the delta spec.
+\- **Time-box exploration**. If a module is too deep to understand in the blast radius pass, note it as a gap and move on. Discovery that takes longer than the change itself has failed the economics test.
+\- **Dead code is not safe to ignore**. If it's in the blast radius, document it. It might be load-bearing in ways you can't see.
+\- **Test assertions reveal intent**. When code is unclear but tests exist, the test assertions tell you what behavior matters. Prioritize reading tests over reading implementation.
+
+\---
+
+\#\# AFTER DELIVERY
+
+After producing the discovery document:
+
+1. Ask the user to validate the behavioral contracts — "Is this what the system actually does?"
+2. Ask the user to resolve the tribal knowledge gaps — these are the highest-risk items
+3. Recommend next step: `spec-architect` (with brownfield delta sections) or `spec-writer` (for simpler changes)
+4. Offer to save as `discovery.md` in the project's `.factory/` directory or equivalent
+
+\---
+
+\#\# ECONOMICS NOTE
+
+Discovery must be worth its cost. If the change is small (single file, clear behavior, good test coverage), skip discovery and go straight to implementation. Discovery pays for itself when:
+
+\- The change touches 3+ files across multiple modules
+\- Test coverage in the blast radius is weak or absent
+\- The codebase uses conventions unfamiliar to the agent
+\- The client can't explain what the code does (tribal knowledge is lost)
+\- The change has integration boundaries with external systems
+
+If none of these apply, a quick read of the relevant files is sufficient — you don't need a formal discovery.
+
+\---
+
+\#\# ATTRIBUTION
+
+This skill builds on:
+\- **Stripe Engineering** — Minions system architecture: context pre-hydration, blast radius scoping, same-tooling principle (stripe.dev/blog/minions, 2026)
+\- **Dark Factory methodology** — Spec-driven development for brownfield, three-phase flow (Discover → Spec Delta → Execute)
+\- **Nate Jones** — Spec-driven development and intent engineering frameworks