predict
Skill6 starsChanged 13 days agoApache-2.0View on GitHub
Forecast future states or outcomes based on current data and trends. Use when estimating future values, projecting trajectories, forecasting outcomes, or anticipating system behavior.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ffroliva/gflow-clitheir own version, first seen Sep 14, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
- ffroliva/gflow-cli★ 367same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository42 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- attributeSkill
- auditSkill
- gap-analysis-workflowSkill
- checkpointSkill
- classifySkill
- compareSkill
- constrainSkill
- critiqueSkill
- debug-workflowSkill
- decomposeSkill
- delegateSkill
- detectSkill
- digital-twin-bootstrapSkill
- digital-twin-sync-workflowSkill
- discover-capabilitiesSkill
- discoverSkill
- executeSkill
- explainSkill
- generateSkill
- groundSkill
- inquireSkill
- integrateSkill
- invokeSkill
- measureSkill
- mutateSkill
- observeSkill
- persistSkill
- perspective-validationSkill
- planSkill
- recallSkill
- receiveSkill
- retrieveSkill
- rollbackSkill
- searchSkill
- sendSkill
- simulateSkill
- stateSkill
- synchronizeSkill
- transformSkill
- transitionSkill
- verifySkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 9 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 46
Look for relevant precedents
- Distinctive: line 48
Establish conditions: Document assumptions about the future
- Distinctive: line 63
Ground prediction: Document evidence and reasoning
- Distinctive: line 206
Verification tools: Read (to verify historical data references)
- Distinctive: line 216
Always provide probability, never claim certainty about future
- Distinctive: line 217
Document assumptions that could invalidate prediction
- Distinctive: line 218
Consider alternative outcomes, especially failure modes
- Distinctive: line 219
Do not predict beyond available data horizon without noting extrapolation
- Very specific: line 235
Never use predict for current state (use measure or observe)
- Distinctive: line 236
Avoid predict when historical data is insufficient
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Intent
Forecast future states or outcomes for a target based on current state, historical patterns, and assumed conditions. This capability consolidates all forecasting tasks (risk, impact, time, etc.) into a single parameterized operation.
Success criteria:
- Prediction for requested target and horizon provided
- Probability or confidence assigned to prediction
- Alternative outcomes considered
- Assumptions explicitly stated
Compatible schemas:
schemas/output_schema.yaml
Inputs
| Parameter | Required | Type | Description |
target | Yes | string | What to predict (metric, state, outcome, event) |
horizon | No | string | Prediction timeframe (e.g., "1 week", "next release", "end of sprint") |
conditions | No | object | Assumed conditions for prediction |
Inputs not listed here are outside the capability's contract: a workflow step that binds them gets W604 (STANDARD v1.1 §5.5).
Procedure
- Define prediction target: Clarify what outcome is being predicted
- Specify the metric, state, or event to forecast
- Establish the prediction horizon
- Note any boundary conditions
- Gather historical data: Collect relevant past observations
- Identify patterns and trends
- Note data quality and coverage
- Look for relevant precedents
- Establish conditions: Document assumptions about the future
- Note what must remain constant
- Identify key variables that could change
- Consider external factors
- Generate prediction: Forecast the most likely outcome
- Apply trend analysis or modeling
- Calculate probability of primary prediction
- Identify alternative outcomes
- Consider alternatives: Evaluate other possible outcomes
- List plausible alternative scenarios
- Assign rough probabilities to alternatives
- Note what would cause each alternative
- Ground prediction: Document evidence and reasoning
- Reference data supporting the prediction
- Note the reasoning chain
- Explicitly state all assumptions
Output Contract
Return a structured object:
prediction:
outcome: any # Predicted value, state, or event
horizon: string # When this prediction applies
probability: number # 0.0-1.0 likelihood of the predicted outcome
alternatives:
- outcome: any # Alternative outcome
probability: number # Likelihood
trigger: string # What would cause this
trajectory: # Optional: predicted path to outcome
- timestamp: string
state: any
reasoning: string # Explanation of prediction logic
confidence: 0..1 # Confidence in prediction methodology
evidence_anchors: ["file:line", "data:source"]
assumptions: [] # Critical assumptions
invalidation_conditions: [] # What would invalidate this predictionField Definitions
| Field | Type | Description |
prediction | any | The prediction: outcome (predicted future state or value) and horizon (timeframe) |
probability | number | 0.0-1.0 likelihood of the predicted outcome |
alternatives | array | Other possible outcomes with triggers |
trajectory | array | Path from current to predicted state |
reasoning | string | Explanation of prediction logic |
invalidation_conditions | array | What would make prediction invalid |
confidence | number | 0.0-1.0 confidence in the prediction methodology (distinct from probability) |
evidence_anchors | array | References to the data the prediction rests on |
assumptions | array | Critical assumptions |
Examples
Example 1: Predict Sprint Completion
Input:
target: "sprint story completion"
horizon: "end of sprint (5 days)"
conditions:
team_size: 4
no_major_blockers: trueOutput:
prediction:
outcome: "7 of 10 stories completed (70%)"
horizon: "end of sprint (5 days)"
probability: 0.65
alternatives:
- outcome: "10 of 10 stories completed (100%)"
probability: 0.15
trigger: "No unexpected blockers, all estimates accurate"
- outcome: "5 of 10 stories completed (50%)"
probability: 0.20
trigger: "Major blocker or team member unavailable"
trajectory:
- timestamp: "Day 2"
state: "3 stories completed"
- timestamp: "Day 4"
state: "5-6 stories completed"
- timestamp: "Day 5"
state: "7 stories completed"
reasoning: "Based on team velocity of 1.5 stories/day and current progress, projecting linear completion. Historical sprints show 70% completion rate."
confidence: 0.7
evidence_anchors:
- "tool:jira:sprint-history"
- "tool:jira:current-burndown"
assumptions:
- "Team velocity remains consistent"
- "Story estimates are accurate"
- "No unplanned work introduced"
invalidation_conditions:
- "Team member becomes unavailable"
- "Critical production incident"
- "Scope change to sprint"Example 2: Predict System Failure
Input:
target: "disk space exhaustion"
horizon: "next 30 days"
conditions:
growth_rate: "current trend"Output:
prediction:
outcome: "Disk will reach 95% capacity"
horizon: "18-22 days"
probability: 0.85
alternatives:
- outcome: "Disk reaches 100% (service outage)"
probability: 0.60
trigger: "No cleanup or expansion action taken"
- outcome: "Capacity remains stable"
probability: 0.10
trigger: "Log rotation reduces growth rate"
trajectory:
- timestamp: "Day 7"
state: "85% capacity"
- timestamp: "Day 14"
state: "90% capacity"
- timestamp: "Day 20"
state: "95% capacity"
reasoning: "Current growth rate of 0.5% per day on 80% utilized 500GB disk. Linear projection shows critical threshold in ~20 days."
confidence: 0.8
evidence_anchors:
- "command:df -h /data"
- "tool:monitoring:disk-trend-7d"
assumptions:
- "Growth rate continues at current pace"
- "No bulk data imports or exports"
- "Log retention policy unchanged"
invalidation_conditions:
- "Growth rate changes significantly"
- "Disk expanded or data archived"
- "Application behavior changes"Verification
- Prediction includes specific outcome and probability
- Horizon is clearly specified
- At least one alternative outcome considered
- Assumptions are explicitly documented
- Evidence supports the prediction reasoning
Verification tools: Read (to verify historical data references)
Safety Constraints
mutation: falserequires_checkpoint: falserequires_approval: falserisk: low
Capability-specific rules:
- Always provide probability, never claim certainty about future
- Document assumptions that could invalidate prediction
- Consider alternative outcomes, especially failure modes
- Do not predict beyond available data horizon without noting extrapolation
- Flag when prediction confidence is too low to be actionable
Composition Patterns
Commonly follows:
measure- Measurements provide basis for predictionsobserve- Current state observations inform predictionsdiscover- Discovered patterns enable predictions
Commonly precedes:
plan- Predictions inform planning decisionscompare- Predicted outcomes can be comparedsimulate- Predictions guide simulation scenarios
Anti-patterns:
- Never use predict for current state (use
measureorobserve) - Avoid predict when historical data is insufficient
Workflow references:
- See
reference/workflow_catalog.yaml#digital_twin_sync_loopfor forecasting in digital twins
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

