starting-point

Determine the correct starting boundary for ambiguous or proof-sensitive tasks.

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/srinitude/skills --skill starting-point
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: starting-point
Source: https://github.com/srinitude/skills/tree/main/skills/starting-point
Command: npx skills add https://github.com/srinitude/skills --skill starting-point

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) and assets (resource) components.

What problem does it solve?

Helps you avoid solving the wrong problem, using the wrong method, or claiming completion without the proof needed to support it.

Core Features & Use Cases

  • Distinguishes the user’s real outcome from a merely prescribed action or proxy metric.
  • Detects when a requested route is weak, contradictory, underpowered, ambiguous, or blocked by authorization.
  • Separates component evidence from whole-outcome proof so you do not overclaim on partial results.
  • Keeps reversible drafting separate from irreversible sending, deleting, renaming, or other external actions.
  • Example use cases include deciding whether to follow a requested workflow, ask one gating question, hold for approval, or hand off to a downstream skill.

Quick Start

Use the starting-point skill to evaluate the user’s goal, identify the proof threshold, and choose the safest valid next step.

Frequently Asked Questions about starting-point

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I determine the correct starting boundary for ambiguous or contradictory task requests?

Route selection evaluates whether a requested workflow can prove the intended outcome by detecting weak, contradictory, or underpowered methods, ensuring you do not solve the wrong problem or overclaim on partial results.

How do I distinguish component evidence from whole-outcome proof to avoid overclaiming completion?

You distinguish component evidence from whole-outcome proof by separating partial task completion metrics from the final required authorization threshold, ensuring downstream handoff occurs only when the whole outcome is fully verified.

Can I use outcome mapping to handle authorization-gated requests before taking irreversible actions?

Yes, outcome mapping handles authorization-gated requests by keeping reversible drafting separate from irreversible external actions like sending or deleting, holding the task for approval when the proof threshold is unmet.

What should I do when the prescribed method for a task contradicts the user's intended outcome?

When the prescribed method contradicts the intended outcome, you should select an alternative valid route, ask one gating question, or perform a downstream handoff to a workflow that can actually prove the desired result.

Does this approach work for proof-sensitive tasks where route choice determines validation success?

Yes, this approach works for proof-sensitive tasks because it explicitly evaluates the prescribed method against the user's intended outcome, ensuring the chosen route meets the evidence threshold required to prove completion.