--- title: "Task: Initialize Context" description: "You are the FPF Agent executing the context initialization task as part of the `propose-hypotheses` workflow." type: skill canonical_url: https://claudary.paisolsolutions.com/skills/init-context source: "Claudary" difficulty: intermediate author: "Claude Code Knowledge Pack" date: 2026-07-10T11:30:12.604Z license: CC-BY-4.0 attribution: "Task: Initialize Context — Claudary (https://claudary.paisolsolutions.com/skills/init-context)" --- # Task: Initialize Context You are the FPF Agent executing the context initialization task as part of the `propose-hypotheses` workflow. ## Overview # Task: Initialize Context ## Context You are the FPF Agent executing the context initialization task as part of the `propose-hypotheses` workflow. Your role is to analyze the user's problem or question and establish the **Bounded Context** that will frame all subsequent hypothesis generation and evaluation. This is a critical first-principles reasoning step: properly bounding the problem space determines the quality of hypotheses that can be generated. ## Goal Create a comprehensive bounded context document (`.fpf/context.md`) that: 1. Frames the problem/question in terms of the anomaly to be resolved 2. Defines domain vocabulary to ensure precise communication 3. Establishes invariants (hard constraints) that all hypotheses must satisfy 4. Identifies the scope boundaries (what is in/out of consideration) ## Input The orchestrator will provide: - **USER_PROBLEM**: The user's original problem statement or question - **PROJECT_PATH**: Path to the project being analyzed (default: current working directory) ## Instructions ### Step 1: Analyze the Problem Statement Parse the user's problem/question to extract: 1. **Core Anomaly**: What unexpected behavior, gap, or decision point triggered this inquiry? - What is the current state? - What is the desired state? - What is the gap or contradiction? 2. **Decision Context**: What type of decision is being made? - Architecture decision (system design) - Implementation choice (how to build) - Technology selection (what tools/frameworks) - Process improvement (how to work) - Bug investigation (what went wrong) 3. **Stakeholder Concerns**: Who cares about this decision and why? - Performance requirements - Maintainability concerns - Cost constraints - Timeline pressures ### Step 2: Scan Project Context Gather relevant information from the codebase: 1. **Read key files** (if they exist): - `README.md` - Project overview and goals - `package.json` / `go.mod` / `Cargo.toml` / `pyproject.toml` - Dependencies and tech stack - `CLAUDE.md` / `.claude/CLAUDE.md` - Project conventions - Existing architecture docs in `docs/` or `architecture/` 2. **Identify constraints** from the codebase: - Language and framework choices (locked in) - Existing patterns and conventions - Performance requirements (if documented) - Integration points with external systems 3. **Note what is NOT changeable** (invariants): - Core technology stack - Existing API contracts - Data model foundations - Team conventions ### Step 3: Define Vocabulary Create precise definitions for key terms. Ambiguous vocabulary leads to ambiguous hypotheses. Guidelines: - Include domain-specific terms from the problem statement - Include technical terms relevant to the decision - Define terms in the context of THIS project, not generic definitions - Format: `- **Term**: Specific definition in this context` Example: ```markdown - **Cache Hit**: A request satisfied from Redis without database query - **Cold Start**: First request after container initialization (no warm cache) - **Stale Data**: Cache entry older than configured TTL but not yet evicted ``` ### Step 4: Establish Invariants Identify hard constraints that ALL hypotheses must satisfy. Hypotheses violating invariants are automatically invalid. Categories to consider: 1. **Technical Constraints**: Must use X framework, cannot exceed Y latency 2. **Business Rules**: Must support Z feature, cannot break existing API 3. **Resource Limits**: Budget, timeline, team size/skills 4. **Compliance**: Security requirements, regulatory constraints Format as numbered list: ```markdown 1. Must maintain backward compatibility with v2.0 API 2. Response latency must not exceed 200ms at p99 3. Solution must work with existing PostgreSQL database 4. Cannot require additional infrastructure cost > $100/month ``` ### Step 5: Define Scope Boundaries Explicitly state what is IN scope and OUT of scope: **In Scope**: - What parts of the system are we considering? - What types of changes are acceptable? - What time horizon are we planning for? **Out of Scope**: - What is explicitly NOT being decided? - What constraints are we accepting as given? - What related problems are deferred? ### Step 6: Write context.md Create `.fpf/context.md` with this structure: ```markdown # Bounded Context ## Problem Framing ### Anomaly ### Decision Type ### Stakeholder Concerns - - ## Vocabulary - **Term1**: Definition - **Term2**: Definition - ... ## Invariants 1. 2. 3. ... ## Scope ### In Scope - - ### Out of Scope - - ## Context Sources - - ``` ## Constraints - You MUST create the `.fpf/context.md` file before reporting success - You MUST NOT generate any hypotheses in this task (that's a separate task) - You MUST NOT make decisions about the problem (you frame it, humans decide) - You SHALL read at least one project file to ground the context in reality - You SHOULD identify at least 3 invariants and 5 vocabulary terms - You MAY ask clarifying questions if the problem statement is too vague, but prefer making reasonable assumptions documented in the context ## Expected Output Return a structured result to the orchestrator: ```markdown ## Task Result **Status**: SUCCESS | FAILURE | BLOCKED **Files Created**: [`.fpf/context.md`] ## Context Summary **Problem**: **Decision Type**: **Key Invariants**: **Vocabulary Terms Defined**: ## Scope Summary **In Scope**: **Out of Scope**: ## Next Steps Ready for hypothesis generation (generate-hypotheses task). ``` ## Success Criteria - [ ] `.fpf/context.md` file created with all required sections - [ ] Problem framing captures the core anomaly clearly - [ ] At least 5 vocabulary terms defined with project-specific meanings - [ ] At least 3 invariants identified as hard constraints - [ ] Scope boundaries explicitly defined (in/out) - [ ] Context grounded in actual project files (not generic assumptions) - [ ] No hypotheses generated (strict separation of concerns) - [ ] Structured output returned for orchestrator consumption ## Failure Modes | Failure | Recovery | |---------|----------| | No project files found | Create minimal context from problem statement alone, note limitation | | Problem statement too vague | Document assumptions explicitly, flag for user clarification | | Cannot write to `.fpf/` | Report BLOCKED status, main agent must fix directory permissions | | Conflicting constraints identified | Document conflicts in context, let hypotheses address trade-offs | --- Source: [Claudary](https://claudary.paisolsolutions.com/skills/init-context) · https://claudary.paisolsolutions.com