# Spec Kit + Archcore

> Connect Spec Kit + Archcore to check feature plans against project decisions and keep specifications, tasks and decision records linked as code changes.

Instruction revision: 3f4e27d4ecd122d2e16aad223ca85e248381598640a1da505775a737a59c9f89
Instruction text: https://archcore.ai/integrations/spec-kit/cooperation.md
Source: https://github.com/archcore-ai/landing — src/recipes/spec-kit/cooperation.md (unpublished)

## Tools

- Archcore — Keeps project decisions and rules in Git so your agent can check feature plans against them.
- Spec Kit — Guides work from project principles through a feature specification, implementation plan, tasks and code.

## How Spec Kit + Archcore work together

Spec Kit + Archcore connects a feature's specification and implementation plan to
the decisions already made in your project. Spec Kit organizes the feature work.
Archcore supplies relevant decisions and keeps new decision records linked to
the feature files.

For example, a feature plan may introduce a calculation method that contradicts
an accepted project decision. The instructions ask the agent to surface the
conflict while you can still change the plan. Once you approve the design, new
architectural decisions are recorded as drafts for separate acceptance.

The instructions also address stale status statements found in the pilot's plans
and research. Read the [pilot findings and instruction changes](/integration-evidence/2026-09-11-spec-workflows.md)
for the measured scope. For native commands and installation, see the
[Spec Kit project](https://github.com/github/spec-kit).

## From a feature specification to checked implementation

The instructions ask your agent to:

1. **Read the principles and decisions.** The agent checks the feature specification and Spec Kit constitution against relevant Archcore decisions. The constitution is the project's agreed set of principles. A missing or blank one is reported for your decision.
2. **Review the feature plan.** Spec Kit keeps the specification, plan and supporting design files. You review them before implementation, with conflicts and open assumptions made explicit.
3. **Link the new decisions.** After design approval, the agent checks for existing decisions before creating draft ADRs in Archcore. Each architecture decision record links to the native feature files and distinguishes approved choices from assumptions.
4. **Implement from the native tasks.** The agent follows Spec Kit's task list, checks code against the approved specification and contracts, and updates current status statements in the plan and research.
5. **Resume with the saved feature context.** A later session reads the feature files and decision records before repeating requirements questions. It reports unfinished work and separates draft decisions from accepted ones.

Spec Kit keeps the feature specification, plan and tasks. The integration asks Archcore to reference those files when recording decisions.


## Benefits & limits

### Keep feature plans connected to project decisions.

You can review the proposed implementation alongside existing decisions, then keep the reasons for new choices linked to the feature files as work proceeds.

### A feature conflicts with an accepted decision

In both pilot runs with the earlier recipe, the agent reported the conflict before planning or implementation and preserved the accepted decision after the owner's resolution.

The benchmark explicitly requested the conflict check. Both runs used project instructions and the accepted ADR because the constitution was blank.

### Specifications, tasks and decisions stay connected

Both runs kept feature files in Spec Kit's native locations and created linked draft ADRs in Archcore. Code passed the benchmark's six primary and four additional contract checks.

Plan and research sections still contained stale claims about which records existed. Passing code tests did not make those documents consistent.

### A later session reviews the result

The recorded recall answers recovered the coupon behavior, draft ADR status and document disagreements from the saved feature work.

Some assumptions had been described as settled decisions. The revised instructions explicitly separate assumptions from owner approval.

### Limits

The earlier recipe completed one coupon-feature scenario twice in Claude Code. The constitution stayed an unfilled template in both runs, so compatibility with a populated constitution remains untested. This revised instruction text has not had a joint run.


## Known limits

- The published instructions are a revision of the measured recipe. They remain experimental until this exact text is tested.
- The pilot used Claude Code 2.1.268, model identifier claude-opus-5[1m], Archcore 0.8.3 and a pinned Spec Kit runtime snapshot documented in the pilot note.
- Two repetitions of one scripted feature do not establish better code, lower cost or compatibility across repositories and agents.
- A populated constitution, extensions, multi-feature work and additional planning tools were not covered by this pilot.
- The instructions rely on the agent following them. Review remains necessary for tests, document consistency and decision approval.