Spec intake
Normalize all starting evidence into a subject spec run. Use this when beginning a Forge spec from code, docs, transcripts, screenshots, URLs, or a sparse user request. Creates the subject slug, frontmatter, evidence ledgers, request archetype, evidence-density classification, and canonical readiness skeleton.From its SKILL.md
npx -y skills add mwarger/forge --skill spec-intakeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 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.
SKILL.md
3.5 KB, as published. Nobody here has run it
Use this skill first.
Goal
Turn raw inputs into a normalized evidence run with:
- a subject slug
- a canonical spec path
- a root specs index path
- a request archetype
- an evidence-density classification
- a critical-decision coverage skeleton
- seeded frontmatter
- initial evidence records
- intake summary
Steps
- Derive the subject slug from the thing being studied or developed.
- Ensure
specs/README.mdexists. - If
specs/README.mdis missing, create it with:- a short title
- a one-line description of the specs tree
- an optional notes section
- a managed block delimited by:
<!-- forge:spec-index:start --><!-- forge:spec-index:end -->
- If
specs/README.mdexists but the managed block is missing, add the managed block without deleting human prose outside it. - Create
specs/<subject>.md. - Create
specs/_artifacts/<subject>/. - Classify every input as:
repodoctranscriptuiuser_statementanswerobservation
- For each input, create an
evidence_unitrecord with:idsource_typesource_refdirectnessauthorityfreshnessindependence_groupextraction_method
- Record
source_origin_keysfrom evidence provenance, not raw file count. - Classify
request_archetype:
featureanalogy_featureparity_cloneintegrationbugfixmigrationrefactorreverse_spec
- Classify
starting_evidence_density:
sparsemixeddense
- Seed
critical_decision_coveragewith these buckets:
core_outcomescope_boundaryimplementation_constraintsdependencies_and_integrationsacceptance_signal
- Seed the spec with:
OverviewIntake SummaryEvidence Model
- Seed sidecars:
manifest.jsonrun-state.jsonbranch-registry.jsoninput-log.mdevidence-ledger.jsonlclaim-ledger.jsonl
- If
UBIQUITOUS-LANGUAGE.mddoes not exist at the project root, create it with an initial set of domain terms extracted from the evidence sources. If it already exists, read it and use existing terms for consistency. Append any new domain terms, entity names, or concepts discovered during intake. - Read
AGENTS.mdat the project root (if it exists). Note project conventions, patterns, and anti-patterns it encodes — these are prior implementation learnings that should inform the new spec rather than be rediscovered. Record relevant conventions asobservationevidence units withsource_type: prior_learnings.
Output rules
Intake Summarystays short.- Detailed intake history stays in sidecars.
- A one-line feature request is still enough to start a run.
- If the source is large, spawn sub-agents to catalog source areas before the main loop starts.
- The root
specs/README.mdis navigational. - The subject spec is the implementation handoff artifact.
sparseanalogy or feature runs should default to clarification if the critical decision buckets are not explicit in evidence.