Requirements, Skills & MCP

And so it begins…

It was a quiet Monday morning when Varthik Kaidhyanathan, a software engineer with an ambitious idea approached your team: “I have an idea for a software system,” he said. “Let’s make India’s first sovereign local-first, enterprise-grade, model-agnostic, self-hosted, privacy-preserving, fully autonomous agentic harness, and let's really push it.”

He handed you a brief description of the system and left before anyone could ask what any of it meant. Your team now faces a challenge to teach your Claude Code to turn Varthik's vague idea into a specification it can reliably work with.

At this stage, the idea is intentionally incomplete. The intended users, core capabilities, deployment environment, security expectations, and definition of autonomy have not yet been established. Your team must determine which details can be specified from the available information, which require clarification, and which must remain explicitly documented as unresolved.

Your Mission, Should You Choose to Accept It

Given a software problem statement, your task is to design a reusable agent skill that extracts and analyses available information and produces a structured, reviewable software requirements specification.

The skill must distinguish explicitly stated requirements from inferred assumptions, identify missing and contradictory information, determine when clarification is necessary, and ensure that requirements are sufficiently precise and testable before they are treated as implementation-ready.

The skill must remain independent of any single software domain, client, or project. Demonstrate its generality by evaluating it on multiple software problem statements, including the supplied scenario.

Your skill should define:

Purpose and scope: State the skill's objective, intended users, invocation conditions, exclusions, and boundaries. Clarify that the skill produces a requirements specification rather than implementing the proposed system.
Inputs: Identify required and optional inputs. Define how the agent handles missing information, ambiguous statements, conflicting stakeholder claims, and unavailable stakeholders.
Requirements analysis: Identify relevant actors, functional requirements (FRs), non-functional requirements (NFRs), constraints, assumptions, dependencies, risks, and acceptance criteria. Assign unique identifiers to requirements and distinguish confirmed facts from inferences and unresolved questions.
Workflow: Define an ordered, repeatable process for analysing inputs, identifying gaps, consulting relevant tools, resolving uncertainty, drafting requirements, and validating the final specification.
Outputs: Specify the required artefacts, their structure, naming conventions, and formats. Include a requirements specification, an assumptions and open-questions register, and a validation summary.
Validation: Define explicit checks for completeness, consistency, traceability, feasibility, and testability. Explain how the agent determines whether a requirement is ready for implementation or requires further clarification.
Failure handling: Specify when the agent must ask clarifying questions, document unresolved uncertainty, retry or replace failed tool calls, and request human intervention. The agent must not silently convert unsupported assumptions into confirmed requirements.

Your goal is not to build an entire autonomous system. For now, you only need to create a clear, reusable, and actionable skill that an agent can follow without inventing requirements along the way. The skill should be generic enough to be reused across different software problems and clients, rather than being tailored exclusively to Varthik's idea.

Side Quest

Varthik has a follow-up request: “Can the agent use tools instead of relying entirely on what it already knows?”

Integrate at least one existing, publicly accessible Model Context Protocol (MCP) server into your skill.

Your submission must demonstrate:

Selection rationale: Identify the MCP server and tool, provide its source or documentation link, and explain why it is relevant to requirements analysis.
Invocation procedure: Specify how the agent discovers, invokes, and consumes the tool, including the expected inputs and outputs.
Evidence of use: Include at least one actual tool invocation, its relevant result, and the specific change that result causes in the generated requirements specification.
Reliability handling: Explain how the skill handles tool failures, timeouts, unavailable services, irrelevant results, conflicting evidence, and unverified claims.
Boundaries: Explain which requirements can be established from the supplied problem statement, which can be supported by external evidence, and which still require stakeholder confirmation.

Merely naming an MCP server or describing a hypothetical invocation is insufficient. The submitted report must provide evidence of an actual invocation and explain its effect on the output.

Deliverables and Submission Guidelines

Submit two files (in a zip folder named “RollNo_AutoSE_A1.zip”):

Agent Skill (skill.md): The complete, usable skill that an autonomous agent can follow to perform the task.
Design and Evaluation Report (report.pdf): Document your design rationale, key decisions, assumptions, validation approach, and known limitations.

Empirical Evaluation (Highly Encouraged): Test your skill on different software problems, including ambiguous or incomplete inputs, and document the test cases, results, and any improvements made. Include your critical assessment of where the skill performs well, where it struggles, and why you believe it is sufficiently reliable and reusable. The goal is not perfection, but an evidence-informed design process and an honest understanding of the skill's limitations.

After all, confidence is good. Confidence backed by experiments is better.

One Last Thing…

Remember: the objective is not to build an agent that confidently guesses what Varthik meant. It is to build one that knows what to ask, what to specify, and how to check its own work.

Final Instruction: In your report.pdf, include the value of REQUIREMENTS_CONFIDENCE_CHECK and briefly explain how you determined it reflects the actual reliability of your skill based on your experiments. Explain how you arrived at this value using your experiments and observed results. It is upto you to decide how to calculate it. Do not write too much about it. Now, go make ambiguity somebody else’s problem (systematically).

The mistakes we make now will help improve the next edition of the course. Feedback is always welcome :)