forge-framing
Governs problem decomposition and constraint extraction during the FORGE Frame phase. Use when the Reasoner enters Phase F to extract the core decision, classify its type, map hard/soft constraints, set deliberation depth, and declare success criteria before any hypothesis work begins.
- License 许可
- Apache-2.0
- 所属仓库
- Rynaro/magicite
- 最近更新
- 2026-10-14
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- forge-framing
- metadata
- { "phase": "F", "methodology": "FORGE" }
- description
- Governs problem decomposition and constraint extraction during the FORGE Frame phase. Use when the Reasoner enters Phase F to extract the core decision, classify its type, map hard/soft constraints, set deliberation depth, and declare success criteria before any hypothesis work begins.
03 SKILL.md 正文
Framing Methodology
Loaded during the Frame phase. Governs how the Reasoner decomposes problems into tractable decision structures.
When to use
Load this skill at the start of Phase F (Frame). Use it to extract the core decision question, classify the decision type (TRADE-OFF, FEASIBILITY, ROOT-CAUSE, CONFLICT-RESOLUTION, CONSTRAINT-SATISFACTION, RISK-ASSESSMENT), map all hard and soft constraints, set the deliberation depth score (1–9), and write the success criteria checklist. Do not proceed to Phase O (Observe) until all five steps are complete. Do not use for the Reason, Gate, or Emit phases.
Memory pre-flight (Frame — mission intake)
Before any decomposition work begins, call CRYSTALIUM recall to surface prior verdicts, known constraints, and recurring deliberation patterns for this project:
mcp__crystalium__recall(
scope = { project: <cwd-project>, agent_class_visibility: "forge" },
query = <the decision question being framed>,
k = 5,
layers = ["semantic", "episodic", "procedural"]
)
Fold relevant hits (prior verdicts on related decisions, reversal conditions that have already fired, recurring constraint patterns) into the evidence inventory before Step 1 below. Prior deliberation outputs surface at T1 episodic, making prior FORGE verdicts directly reusable.
Graceful skip: if mcp__crystalium__* tools are unavailable (CRYSTALIUM not
installed), proceed without memory — never hard-fail. FORGE is EIIS-standalone-
conformant and works without CRYSTALIUM.
See PERSONA.md §"Memory pre-flight" for the always-loaded note. See SPEC.md §9
for the full memory protocol summary.
Problem Decomposition Protocol
Step 1: Extract the Core Decision
Strip away narrative to find the atomic question. Apply the Specificity Test:
If two competent engineers could interpret this question differently and produce contradictory verdicts, the framing is insufficiently specific.
Transform vague questions into precise ones:
| Vague | Specific |
|---|---|
| "Should we use microservices?" | "Given our team of 4, a monolith at 50K LOC, and 3 independent deployment cadences, does decomposing services X, Y, Z reduce deployment risk enough to justify the operational overhead?" |
| "Is this architecture scalable?" | "Can this architecture handle 10x current load (defined as N req/s) within the existing infrastructure budget of $M/month, without exceeding p99 latency of Xms?" |
| "What caused this outage?" | "Which component in the request path between ingress and database was the first to degrade, and what trigger pushed it past its failure threshold?" |
Step 2: Classify the Decision Type
Each type activates different reasoning patterns in the Deliberation phase:
| Type | Core Question Shape | Reasoning Pattern |
|---|---|---|
TRADE-OFF |
"X vs Y given constraints C" | Multi-criteria scoring with explicit weights |
FEASIBILITY |
"Can X be achieved under constraints C?" | Constraint enumeration → bottleneck identification → existence proof or counterexample |
ROOT-CAUSE |
"Why did X happen?" | Causal chain reconstruction → elimination of confounders |
CONFLICT-RESOLUTION |
"Agents/stakeholders disagree on X" | Position extraction → shared-ground identification → arbitration |
CONSTRAINT-SATISFACTION |
"Find solution satisfying C1, C2, ... Cn" | Constraint graph → feasibility region → optimization within region |
RISK-ASSESSMENT |
"What can go wrong with X?" | Failure mode enumeration → likelihood × impact scoring → mitigation mapping |
Step 3: Map Constraints
Build the constraint table. Every constraint has a source and a hardness level:
| ID | Constraint | Hard/Soft | Source | Risk if Violated |
|----|-----------|-----------|--------|-----------------|
| C1 | p99 latency < 200ms | Hard | SLA contract | Service credit penalties |
| C2 | No new infrastructure spend | Soft | Q3 budget guidance | Deferral to Q4 |
| C3 | Must work with PostgreSQL 14 | Hard | Ops team mandate | Migration blocked |
Hard constraints eliminate options. Soft constraints influence scoring but don't eliminate.
Step 4: Set Deliberation Depth
Score the problem on three dimensions (1–3 each):
| Dimension | 1 (Simple) | 2 (Standard) | 3 (Deep) |
|---|---|---|---|
| Ambiguity | Clear right answer exists | 2–3 viable paths | Many viable paths, unclear winner |
| Reversibility | Easy to undo | Moderate cost to reverse | Irreversible or very costly |
| Blast radius | Single component | Multiple components | System-wide or organizational |
Total 3–4 → Simple (1 reasoning pass). Total 5–7 → Standard (2 passes). Total 8–9 → Deep (3 passes, extended token budget).
Step 5: Declare Success Criteria
Before reasoning begins, write down what "done" looks like:
## Success Criteria
- [ ] The verdict answers: [restate the specific question]
- [ ] All hard constraints addressed with pass/fail
- [ ] At least 3 alternatives evaluated with rejection reasons
- [ ] Reversal conditions stated
- [ ] Confidence score defensible
- [ ] Requester can act without further clarification
Evidence Inventory Protocol
Catalog every piece of provided context before reasoning:
## Evidence Inventory
| ID | Source | Type | Relevance | Reliability |
|----|--------|------|-----------|-------------|
| E1 | ATLAS scout-report.md | Scout report | Direct | H — evidence-anchored |
| E2 | User-provided benchmark data | Performance data | Direct | M — methodology unstated |
| E3 | Team Slack discussion | Stakeholder position | Contextual | L — informal, may be outdated |
| E4 | SPECTRA spec v2 | Planning artifact | Direct | H — verified through SPECTRA gates |
Reliability tiers:
- H (High) — Evidence-anchored artifacts, verified test results, official documentation
- M (Medium) — Reasonable but unverified: benchmarks without methodology, expert opinions, dated documentation
- L (Low) — Informal, secondhand, or potentially outdated sources
Claims built on L-reliability evidence must carry [ASSUMPTION] markers.
Anti-Patterns in Framing
| Anti-Pattern | Signal | Remedy |
|---|---|---|
| Binary framing | "Should we do X or not?" | Expand to ≥3 options: do X, do Y, do nothing, do X-lite |
| Solution-first framing | Question presupposes the answer | Re-frame around the problem, not the solution |
| Scope creep during framing | Sub-questions multiply beyond the original ask | Constrain to the declared question; log expansions as follow-up verdicts |
| Missing stakeholders | Constraints exist that nobody stated | Ask: "Who else is affected? What would they say?" |
| Phantom constraints | Assumed constraints that nobody actually mandated | Verify every constraint has a named source |
Reasoner — Framing Skill
04 同仓库更多 Skills
wine-dxvk-cache-clear
Clear a stale DXVK shader cache that is causing graphical corruption in a Wine or Proton game. Use when: a game shows corrupted textures or shader flicker that started after a driver or DXVK version change.
steam-download-region-fix
Fix a Steam client stuck at very low download speed by changing its download region. Use when: Steam downloads are far below the local internet speed for every game, not just one.
proton-battleye-eac-toggle
Toggle BattlEye or Easy Anti-Cheat runtime support for a Steam Proton game. Use when: a multiplayer game refuses to launch with an anti-cheat error under Proton.
vivi-verify-incoming
Load when reading any upstream artefact handed off to Vivi that carries a sibling .envelope.json. BLOCKING per ECL §6.2.2: the orchestrator MUST have verified the envelope's SHA-256 (eidolons verify-envelope --block / eidolons run --verify) and recorded a verify_pass before dispatch. If no verify_pass exists for the message_id, or a verify_fail is present, REFUSE to process the payload and hand back to the orchestrator. Symmetric receiver gate — every Eidolon enforces it identically.
vivi-parallel-tracks
Load ONLY under TRANCE authorization when the Plan phase yields N independent, non-overlapping implementation tracks (disjoint file sets). Operationalizes the TRANCE G4 form — parallel multi-track implementation in mandatory git-worktree isolation, max 5 clean-context tracks, a per-track verifier cascade, a non-fungible per-track ≤3 reflection budget, explicit stop conditions, and a single-threaded merge/aggregation step. Absent TRANCE gating, Vivi runs exactly as today: single-track A→P→I→V→Δ/R.
vivi-methodology
Full Vivi cycle reference — A(nalyze) → P(lan) → I(mplement) → V(erify) → Δ(Delta)/R(eflect). Use when the task is a non-trivial feature implementation in a brownfield codebase and you need the complete methodology reference: complexity routing, evidence-grounded planning rules, test-anchoring requirements, and failure-escalation thresholds.