agentsclimarketplace

Create tech spec

Skill lhenrique42/ai-templates/skills/create-tech-spec

Templates for agents, skills, prompts and instructions

Install
npx -y skills add lhenrique42/ai-templates --skill create-tech-spec

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Create Technical Specifications from existing PRDs, translating product requirements into architectural decisions and implementation guidance. Use when asked to create a tech spec, define architecture, or plan implementation for a feature with an existing PRD. Do not use for PRD creation, task breakdowns, or direct code implementation.

SKILL.md

4.6 KB, as published. Nobody here has run it

Create Technical Specification

Outcome

Create one standardized technical specification markdown file derived from an existing PRD.

When to Use

  • User asks to create a technical specification from an existing PRD
  • User asks to define architecture for a feature already described in product terms
  • User asks for implementation planning guidance at design level (without coding or task decomposition)

Do Not Use

  • Creating PRDs from feature ideas
  • Breaking work into sprint tasks, tickets, or estimates
  • Writing production code or patch-level implementation

Required Inputs

  • Existing PRD content or path
  • Optional constraints: deadlines, compliance, infrastructure, scale expectations

Workflow

1) Confirm PRD Input and Scope

Extract implementation-relevant requirements from the PRD.

Capture:

  • Feature intent and success metrics
  • Functional requirements and non-functional requirements
  • Constraints, dependencies, and open questions
  • Explicit out-of-scope boundaries

Decision points:

  • If no PRD is provided, ask for a PRD path or pause and direct user to create one first.
  • If PRD is incomplete, request targeted clarifications and mark unresolved items as TBD.
  • If scope is too broad, split into MVP scope and later-phase considerations.

2) Perform Deep Project Analysis

Analyze the current codebase and architecture context before proposing solutions.

Analyze:

  • Existing modules, services, and integration points
  • Data model and data flow impact
  • Existing patterns and architectural constraints
  • Operational concerns (deployment, monitoring, reliability)

Decision points:

  • If existing architecture already supports the feature, prefer extension over replacement.
  • If constraints conflict (for example, performance vs. cost), present tradeoffs with a recommendation.
  • If codebase context is insufficient, document assumptions explicitly.

3) Research Standards, Technologies, and Rules

Use external research tools to reduce technical and domain uncertainty.

Tool usage expectations:

  • Use Context7 MCP for framework/library patterns, API behavior, and architecture best practices.
  • Use Web Search for domain policies, business rules, or regulatory guidance when relevant.

Decision points:

  • If authoritative guidance conflicts with current architecture, present options and migration risk.
  • If no reliable source is found, record the gap in open questions rather than guessing.

4) Design the Technical Approach

Translate PRD requirements into concrete design decisions.

Include:

  • Architecture overview
  • Components and responsibilities
  • Data model changes and interfaces
  • API/event contracts (if applicable)
  • Non-functional strategy (security, privacy, performance, reliability)
  • Rollout and compatibility considerations
  • Risks and mitigations

5) Draft the Technical Spec

  1. Locate the project tasks directory using this priority:
    • Existing tasks/
    • Existing project-tasks/
    • Existing docs/tasks/
    • Existing .github/tasks/
    • If none exist, create tasks/
  2. Create file name: YYYY-MM-DD-tech-spec-<feature-slug>.md
  3. Draft the spec using Tech spec template
  4. Ensure traceability from PRD requirements to technical decisions.

Drafting rules:

  • Keep technical depth at architecture/spec level.
  • Avoid ticket-level task breakdown.
  • Do not include direct code implementation.

6) Quality Check Before Finalizing

Completion checks:

  • Every major PRD requirement maps to a technical decision or explicit rationale.
  • Architecture and interface boundaries are clear.
  • Non-functional requirements are addressed with measurable targets where possible.
  • Dependencies, risks, and migration/rollback considerations are documented.
  • Open questions and assumptions are explicit.
  • No PRD authoring content, no task decomposition, and no code patches.

7) Return Result

Provide:

  • Created file path
  • Short summary of architecture direction
  • Key tradeoffs and decisions
  • Remaining open questions requiring user input

Output Contract

The generated technical specification should be a single markdown file in the tasks directory and follow the sections in Tech spec template.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.