We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/venikman/fpf-agent-stack'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
agent-skills-spec.json•5.84 KiB
{
"skills": [
{
"name": "fpf-hypothesize",
"description": "Generate 3–7 competing hypotheses/solutions for a problem (Abduction). Use at the start of an FPF-style ADI cycle before verification/validation; outputs hypothesis cards with assumptions, discriminators (tests that would distinguish options), and key risks.",
"compatibility": "Any agent runtime that supports Agent Skills (SKILL.md). No external tools required; may optionally read local project docs if available.",
"metadata": {
"stack": "fpf-skill-stack",
"module": "1",
"phase": "abduction",
"version": "0.1.0"
},
"instructions": "This skill produces a *portfolio* of hypotheses, not a final decision.\n\nDefinitions (local to this skill):\n- Hypothesis: a candidate explanation/solution/approach that could plausibly satisfy the objective.\n- Abduction: generating plausible hypotheses given incomplete information.\n\nActivation cues:\n- User asks \"what should we do / which approach / design / architecture / strategy\" AND there is meaningful uncertainty or multiple viable routes.\n- You are about to implement something non-trivial and need options before committing.\n\nInputs to extract (do not ask questions unless missing info blocks reasonable hypotheses):\n- Objective: what \"success\" means (one sentence).\n- Constraints: hard limits (budget/time/tech/legal/safety), and \"must not\" rules.\n- Context: existing system, stakeholders, environment.\n- Evaluation axes: cost, risk, performance, maintainability, time-to-deliver, etc. (2–6 axes).\n\nProcedure:\n1) Restate the problem in 1–2 sentences.\n - If underspecified, proceed with explicit assumptions.\n - Ask at most 1 clarifying question only if it would change the hypothesis set materially.\n\n2) Generate 3–7 hypotheses with deliberate diversity:\n - At least 1 conservative/standard approach.\n - At least 1 \"middle\" approach (pragmatic hybrid).\n - At least 1 radical option (different architecture/assumption).\n - Avoid \"same idea with different adjectives\".\n\n3) For each hypothesis, output a \"Hypothesis Card\" with this exact schema:\n\nHypothesis Card template (copy per hypothesis):\n- ID: H1, H2, …\n- Title: short noun phrase\n- Type: conservative | hybrid | radical\n- One-line summary: what you would do\n- Mechanism: 3–6 bullets describing how it works (concrete steps/components)\n- Preconditions: what must be true for this to be viable\n- Upsides: 2–5 bullets\n- Failure modes / risks: 2–6 bullets (include how it fails, not just \"it\u2019s risky\")\n- Assumptions: 2–6 bullets (state unknowns as assumptions, not facts)\n- Discriminators: 2–5 bullets of tests/evidence that would distinguish this hypothesis from others\n - Each discriminator should be falsifiable (could come back \"no\").\n- Next step (non-binding): what to check first if we pursue it\n\n4) Portfolio sanity checks (must pass):\n- Coverage: hypotheses collectively span the main design space (not one narrow corner).\n- Distinguishability: each hypothesis has ≥2 discriminators that differ from others.\n- Testability: discriminators can be answered by inspection, small experiment, benchmark, or targeted research.\n- Non-commitment: you do not \"pick the winner\" yet; you only propose options.\n\nOutput format:\n- Start with a compact \"Problem Frame\" (objective + constraints + assumptions).\n- Then list Hypothesis Cards H1…Hn.\n\nExample (mini):\nProblem Frame:\n- Objective: Reduce API latency while keeping infra cost stable.\n- Constraints: No vendor lock-in; must ship in 2 weeks.\n- Assumptions: Current bottleneck is DB reads.\n\nH1 … (cards follow)"
},
{
"name": "fpf-hypothesis-curate",
"description": "Maintain and refine a hypothesis portfolio for Module 1 (Abduction): add user-supplied hypotheses, deduplicate near-duplicates, enforce stable IDs, and keep hypothesis cards comparable for later verification/validation.",
"compatibility": "Any agent runtime that supports Agent Skills (SKILL.md). No external tools required.",
"metadata": {
"stack": "fpf-skill-stack",
"module": "1",
"phase": "abduction",
"version": "0.1.0"
},
"instructions": "This skill is for *editing* the hypothesis set without drifting into \"decision-making\".\n\nWhen to use:\n- The user says \"add this option\", \"include another approach\", \"replace H2 with …\".\n- Hypotheses are redundant, vague, or incomparable.\n- You need stable IDs before Module 2 (Deduction/verification) and Module 3 (Induction/validation).\n\nInputs:\n- Existing hypothesis set (H1…Hn).\n- New hypothesis text (from user or agent).\n- Any updated constraints/context.\n\nProcedure:\n1) Preserve stable IDs:\n- Never renumber existing hypotheses unless explicitly requested.\n- If you delete a hypothesis, mark it as \"Removed\" and keep a short reason + date.\n- New hypotheses get the next available ID (e.g., H6).\n\n2) Normalize wording so cards are comparable:\n- Titles are short noun phrases.\n- \"Mechanism\" is concrete steps/components, not slogans.\n- \"Assumptions\" are explicit and separated from \"facts\".\n\n3) Deduplicate:\n- If a new hypothesis is a near-duplicate of an existing one:\n - Merge it into the existing hypothesis card.\n - Add the unique discriminators/risks it introduced.\n - Record an \"Alias\" line in the card: \"Alias: <user phrasing>\".\n\n4) Enforce minimum completeness:\nEach hypothesis must have:\n- Type (conservative/hybrid/radical)\n- Mechanism (≥3 bullets)\n- Risks (≥2 bullets)\n- Assumptions (≥2 bullets)\n- Discriminators (≥2 bullets)\n\nIf missing, fill gaps by asking one targeted question OR by stating assumptions clearly.\n\n5) Output:\n- Updated hypothesis list (H1…Hn) with only the changed cards fully expanded.\n- A concise \"Change Log\":\n - Added: …\n - Modified: …\n - Removed: …"
}
]
}