That depends on several things. Unfortunately, the PDI DSS is a bit vague in some areas, and different auditors interpret things differently. Expect your first audit to by 80% figuring out what you need to prepare, 20% actually getting it together, and then expect future audits to go more smoothly. But your QSA will tell you what he/she expects.
In general, though, you should have written polices for how you protect your data (backups, live, etc) and be able to produce logs and evidence that shows that you follow procedures.
For example, to satisfy section 6, developers need to have a documented development process. We do, and our process includes steps like code reviews (so we provide copies of completed code reviews) procedures for asking admins to publish a specific tagged item from source control to address separation of concerns (so we provide change request tickets that specify which version of source code gets published on what date/time).
The same goes with the rest of the audit. Have your procedures documented, and provide proof that you follow those procedures.
As for how detailed the policies should be, you should build your paper trail into the policies, so that the auditor knows what to expect for documentation, and so that you force yourself to collect the documentation throughout the year. It makes things a LOT easier. Include things in your polices like "All changes are logged in (name a system)" and then actually log your changes in that system.
Odds are, your current practices won't 100% meet the requirements, or you won't be able to provide that documentation. Generally that seems to be expected on a first audit (or so I gather from our auditors) and the first audit is sort of an eye-opener. It teaches you where you need to improve your polices (and improve them right now). You will likely have the opportunity to provide what you have, and start drafting new policies under the guidance of your auditor. In subsequent years, expect less leniency.
